Exactly.

TBH @User knows the internals better than I do, but IIRC this is a known issue right now where after a failover to a different colo, we don't proactively migrate the object back.

That is my understanding.. there will probably be a much better coverage world-wide, but probably not every single colo. But I am not the definitive source on this

To be clear, they can be accessed from any colo (today). But no, DOs have special requirements since they are stateful/persistent and likely won't run in the smallest of colos for the foreseeable future, but our goal is to have them close to enough to everyone that you shouldn't have to care.

Yeah, I need to fix that. 😦

Does that apply to DOs with unique IDs too? Or just named DOs?

All DOs. I'm only partially caught up on what was said above, but they don't fail over across the world, for what it's worth.

It sounds like someone said they saw an object in LAX and then in EU, which is not possible

It might be in LAX and then SJC

(for example)

Right that’s what I saw.

So, can i hope that get at least one here on Brazil (or close)?

@User Eventually for sure. Our team is really eager to make this work well worldwide, it's one of the big benefits of DOs IMO.

For now you'll have to hop to North America though 😦

I really hope this helps us in SA https://blog.cloudflare.com/expanding-to-25-plus-cities-in-brazil/

For us round trip latency to the DO is what matters. If there was none in South America or Australia for example we’d have to keep our own servers running there which makes our session management much more complex than switching over to cloudflare completely.

Yes, that what i was thinking... today only São Paulo get my regular worker traffic, and our DO are all to New Jersey. We will release our solution this month and keep in closed beta until end of the year, but after that all those incremental delays will be vary bad for our solution, sometimes we need to wait 2-3 seconds to update one document because several round trips.

South America is definitely planned, when I say it won't run in every colo I just mean that some of our PoPs are too small and there is a bigger colo within 10ms anyway

Out of curiosity, for your use case would you prefer they all be in Brazil?

In the next 1-2 year 99% of our clients (for that particular solution) will be here... So yes...

We have other solutions that we plan to migrate to cloudflare workers + DO, and have more coverage worldwide, but we are using this first product to benchmark our needs before we start our main product migration.

Also, here in Brazil we have the LGPD, and similar to the EU GDPR, for some contracts we need to keep our data here to be compliance.

Out of curiosity, if we supported "ephemeral objects" -- like durable objects, but with no persistent storage -- in all colos, would that solve your problem?

That would work, yes, since I would just need to delegate storage requests to another DO, but those wouldn't be in the critical latency path. Most convenient for that would be if I could create a new websocket connection from that ephemeral DO to the persistent DO.

The question is not for me, but that also can help our user case too, the majority of our DOs are storageless.

can you use kv with itty-durable?

What's likely for DO storage in Australia which has multiple POPs, but aren't considered close to each other (probably 20-40ms between if replicating a write to 2 other POPs). Currently DO's are created in Singapore (160-180ms away). Haven't had to rely upon Singapore for over 8 years as there are multiple local regions for AWS, Azure, Google.

Of course…

I don't think so, as the main reason that Itty-Durable exists is to remove the need for performing fetch requests to your DO, which aren't necessary for KV anyway.

It's weird that sometimes

wrangler tail

is showing it's logs of the durable object, and sometimes it doesn't.