Quick question on the best way to store data. I want to store analytics data in a durable object, and I'm wondering what the recommended way is. Option 1: Key:

2021-03-04

Value:

{
  "opens": 104,
  "devices": {
    "mobile": 84,
    "desktop": 20
  }
}

Option 2: Key:

opens/2021-03-04

Value:

104

Key:

devices/2021-03-04

Value:

{
  "mobile": 84,
  "desktop": 20
}

Both options would allow me to fetch the data for a given timespan, with

state.storage.list()

and the appropriate

start

and

end

. I'm leaning towards option 2, since it would avoid the transaction issues I've had with concurrent requests failing (

Transaction failed due to conflict while processing a put()

), but I wanted to ask which method is the best, most performant and most future-proof way to go about it.

are opens just the sum of devices? seems like you only need the latter of option 2 in that case.

opens

is just one of the metrics I want to track, there will be quite a few more (thinking of clicks, scroll position, duration, countries, etc.). So the question is more, should I create many

metric + time

keys, or just a

time

key with a big object containing all the metrics?

General question that I will soon be (load)testing: rps limits have been mentioned multiple times for DO storage, but what about network/infra? In my case it's websocket connections created by thousands, with burst patterns occurring. Does anyone ever witnessed a DO getting hit by something like 5/10k requests over a second? Again, I'm asking for the networking part, for the storage I already have figured out a strategy to have predictable access rate to storage. The theory tells me that it all depends on how fast the code running as the DO can process a given request, but I prefer asking the stupid question regardless

For now I assumed the worst and built a parent/children set of DO's to handle the incoming load in a scalable way

i think it really depends on your reading/writing patterns (ie, are all metrics written at once? and read at once?). hard to say until we have an idea how DO storage is billed, but in general i feel like as few reads/writes as possible is probably best... if you need more granular queries you might be better off rolling them up into your own index.

As a general rule, transactions that are continuously contended on a single key will resolve on retry faster than transactions contended on multiple keys — although the obvious exception to that is that particularly large writes may take longer than smaller writes (minor additional time per requests, but if you have a sizable number of persistent writes that you're executing simultaneously from a single worker, it may become significant when multiplied up).

The scaling theory behind DO is that you can horizontally scale them but having a DO per [whatever the smallest unit of mutually relevant information is: a single chat room, a single document, a single mailbox, etc]. If you have a situation where you definitely still need to do lots of writes per transaction, a simple solution may be to write keys that will not require a transaction and then collate them later.

My issue is that I may have a "room" with about 50k clients connected 😉

For example, you could write keys like

[date]-[random number]

for each incoming request that you want to log metadata about and then schedule a daily cron trigger worker (https://developers.cloudflare.com/workers/platform/cron-triggers) that could call out to your DO(s) and tell it/them to collate the previous day's entries into a single object with a key like

collated-[date]

etc and then delete the previous day's entries. This would let you ensure you received zero-contention writes, thus maintaining high performance while still getting you the analytics behavior you want.

yes, that's kinda what I plan to do for analytics

but for the actual live part, is where you don't even realise I'm talking about building a freaking SPoF allowing many thousand of people of communicate in some ways!

I also have the consideration that DO's are beta and don't want to risk losing a DO for any reason

having redundancy for resiliency is needed as I feel it

so to be clear

do you mean that each of the many thousands of people will be sent every single message written by each person?

oh hold up

I was replying primarily to @User usecase, let me read through yours real quick, my apologies for the mix up

I mean in theory they will be able to send all at the same time a message, the room state then can be refreshed with delays

oh sorry!

hahaha you're good jsut gimme a sec 🙂

np 😄

Alright I think I'm caught up

To answer your question, if you have some remarkably high load on a single DO, that might not yield the best performance but ultimately, yes, the throughput is going to largely be based on how fast your code and how fast your queries can complete. My recommendations for you are going to be to execute writes as they come in against both persistent storage (

state.storage

) and an in-memory state (

this.XYZ

) limited-length buffer (ie: ring/circular - https://stackoverflow.com/questions/1583123/circular-buffer-in-javascript presents some ideas). Then you can serve read-requests from in-memory state and only reload from persistent storage upon (re)initialization of your DO.

thank you for the answer, you're giving me the confirmation I needed. So you would buffer the writes with a ring buffer if I understand correctly. I had thought about this, but eventually I decided to go for another radical and maybe hacky approach. I'll stick to my parent/children architecture for now. And yes we are trying to get DO's fit a high load use case that would normally require some badass plumbing: circumstances made us give it a go with DO's, and I'm quite excited to begin testing this uncommon approach. I'll be happy to share a more comprehensive overview of what we are implementing very soon (maybe tomorrow)!

Awesome, glad I could help. I'm excited to see what it is that you're working on and look forward to it!

if all goes as planned you should even be able to see it in action publicly somewhere soon enough...

Is the waitUntil durable object method subject to the same 30s limit as a normal worker?

yes

Is there any plan to support some kind of graceful shutdown notification/callback? I would be happy even for some "best effort", without any guarantees. Basically "We are going to scale this DO down unless it will receive more requests in the next xx seconds".