Then how does the Workers Runtime know where to send requests made using the stub?

It's either embedded in the ID (newUniqueId) or we use a hash mod

Objects can be relocated, which requires leaving behind a pointer. But we don't just distribute every ID's location everywhere

That works for newUniqueId, but I don't think it explains idFromName. The information that "brett" was created in e.g. ARN must somehow be pushed to other colos.

If you know (from any colo) that a non-EU object exists elsewhere, would you not be able to know the same for an EU object?

We don't know that, we just know which colo to contact to see if it does (the hash mod noted above)

Because everyone contacts the same colo for that object

Is the colo that you contact the same colo that would create the object if it doesn't exist?

Does that mean idFromName objects are not necessarily created in the closest DO-capable colo?

That's right, that way 2 people around the world can ask for an object at the exact same time and end up at the same place in the same object

Kinda, yeah. They are immediately relocated to the nearby colo, they leave behind a pointer. That's the "cached lookup" we have to do that we talk about for

idFromName

But info about that object is only in those 2 colos now (and also, Jurisdictional objects stay within their Jursidiction)

Thanks for taking time to explain some of the architecture DOs - it makes a lot more sense now. This also explains why names can't be unique across jurisdictions. It is because names hashed with EU jurisdiction map to a different (and smaller) pool of colos, so the "colo to contact" would very likely be different than if not using a jurisdiction. Have I got it right?

Close, there's a little more, this probably warrants a blog post at some point

Please do! Would be very interesting to read about 🙂

In that sense its faster for us to cache a DO Id on kv, than to invoke it with id from a known name. The same regarding creating using newUniqueId. The problem is the consistency of that creation... The things you explained are indeed relevant. But if we are using some kind uuid to referend the DO, if its local to a jurisdiction, we have to store the jurisdiction, the uuid and the DO id.

if you're ok with using an opaque id, why would newUniqueId not work for you? jurisdictions for those have been available for quite some time, https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#restricting-objects-to-a-jurisdiction

> In that sense its faster for us to cache a DO Id on kv, than to invoke it with id from a known name. Not sure I follow, we cache the relocation, so it's at worst equal to KV (faster really, for reasons)

Thanks! I do appreciate you corrected me on this.

I misunderstood, I thought the way you handled all that routing was worse, than having the value cached on the kv.

Therefor my current design is correct, my previous understanding is correct.

My use case is to call from the worker a known DO server, that I expect to be in the closest colo. At the moment, I'm creating using the known name, but as you explained it bounces a bit, till it gets closer.

I'm not, because with an opaque id, I had a consistency issue on creation, like you already handle for me... 🙂

what consistency issue on creation are you talking about?

Well, if I have a worker starting in Portugal for instance, and I need to create the DO that will manage stuff for Portugal, its created in Madrid actually, Spain. But when the worker gets triggered, nothing prevents another worker to be triggered at the same time, as in both are going to try to create that DO for Portugal. If I used an opaque id, I could have concurrency issues placing on the kv "Portugal->Opaque Id", that is why I created with IdFromName

That's precisely the issue brett explained quite well why they used that hash mod algorithm to make it deterministic where the do gets "located"

ah, so KV consistency issues. If what you're basically saying is opaque IDs are inconvenient because you have to store them somewhere - I'd agree with you.

KV isn't the only place to store them though

TIL I don't need service bindings to call a DO from another worker

cuts my requests in half yay