If yall are saying you would like to a have a product that pushes data to every single CF colo and keeps it there, that's a different product, and is not likely to be cheaper than a DO or KV request

Ok, I've misunderstood the marketing presentation of KV ( believe that all the KV are cloned all around the 285 PoPs if it's a hot key )

if there is something unclear about the diagrams here https://developers.cloudflare.com/workers/learning/how-kv-works/ let me know and I can relay it to the KV engineering manager

The diagram are good, I've just re-checked, and it's correctly said it's only cached on the colo, my mistake!

If you want something pushed to many locations you could use something like upstash global tables (but obviously way more expensive because global push replication is expensive)

QS Bindings please!

But also just more that we get read access to whatever database stores DO ids

So maybe, given an email(name), tell me whether a DO exists, what jurisdiction it has, and the region it was set to

Or a string id too?

you'd have to know the jurisdiction to look for because an idFromName(email) is different than jurisdiction(eu).idFromName(email)

I guess just a string ID then?

In my scenario, we only known the email address ( or we need to uses a lookup central system to associate newUniqueId() and email address )

Until CF do the fix planned on the roadmap to prevent the case of multiple DO instances can't start because their shared memory is greater than 128MB, I'm searching a way to mitigate the risk. Is it possible inside the same DO script to have multiple classes ( like in the CF chat-demo ChatRoom / RateLimiter ) but where all classes are extended from a common class ( « export class MyClass1 extend CommonClass », « export class MyClass2 extend CommonClass » etc. In this scenario, is the 128MB is still shared between MyClass1 and MyClass2 ? ( there both using the same worker fetch() If it's still share the same memory, what could be the more elegant way to prevent a shared memory ? A radical solution should be to create N workers with different name classes ( MyClassN extend CommonClass )

You could always use state.blockConcurrencyWhile for that?

When you 2 instances of the same class on the same colo, if one uses 100MB and the second 27MB, and then the 2nd instance increase is storage, @ckoeninger explained that both of the instances are killed. And they will be reloaded, then if I keep the classic setup to load the storage at first load, this will crash again in loop. If I understood correctly blockConcurrencyWhile() it's more to block other requests until intitialization complete, but this will not prevent the crash/kill of the instance because of their total shared memory is over the limit of 128MB

Yeah, but if you block when you start processing a Request, you will basically never have two Requests being processed at once

I'll investigate about this blockConcurrencyWhile() and how to uses it to prevent problem of shared memory for multiple instances of the same DO on a same colo. Do you known if in the CF demo chat, the 2 classes of the same script ChatRoom and RateLimiter share the same 128MB ? Or if only ChatRoom instances got 128MB and RateLimiter got 128MB

Each exported class gets 128 mb per instance

currently two different instances of two different classes in the same script on the same machine can share the same memory. I wouldn't suggest you plan around that one way or the other though, since it's subject to change, and as I said earlier we're looking at changes in this area.

what are you actually doing with memory that you're concerned about? have you run into any problems in practice?

Not yet been face to theses problems, but before starting to dev something for weeks, I'm trying to understood the limits, and I want to be sure I'm not doing something that will break randomly because of this shared memory eviction.

Understood. What's happening if there is on the same colo 1.000 active instances of a same DO class, each of them uses 128k, so they uses the 128MB total shared memory, and then a new instance is created ? There is a new VM allocating 128MB for this new instance?

A colo has more than one server not all 1000 will be on the same server

tons of

Network connection lost

errors just now - when these are thrown DO -> DO, does that indicate a problem in the calling colo? or the target colo

I think the issue is in DFW - see nothing on status yet

Team is already working on it 🙂

oh the humanity!

seems to be everywhere

definitely the largest number of errors I've seen in a sustained period so far - but could be specific to my setup