If the DO is far away from where you're currently at, that same user already created that row from a location that was close. If they moved after that, and this is the first signal you have that they moved, what do you expect to happen?

Guillame's current solution to send everything through 1 DO globally is going to be worse in that respect, unless his traffic is generally centered around that DO already

it's depends of cases, our UX scenario login is in 2 screens, 1st you fill the email then we redirect you to your a new screen asking the password if you're exists, or we move to the signup screen. After the 1st screen with the email, we need to known if the users exsits. We have multiple options for that: - Using a newUniqueId() and associate this id/email to a KV/D1/... storage as a lookup service - Using a idFromName(email), slower than newUniqueId(), if it's not exists, we also need to do it a 2nd time in the EU jurisdiction ( 2x DO to start for may be nothing ) My central DO isn't perfect, but KV/D1 require to keep the email hashed (require CPU time) and KV will have cold keys only (so a 2nd round-trip to the central KV is required). So the DO central lookup service is based in EU, our service is more around EU so it's OK, but yes if a US person fill the email, this require to connect to the DO in EU. But at least it's based only on newUniqueId() and don't require to start 2 DO for nothing

I’m not sure I follow? Does this have something to do with the auto-DO-migrator?

one recent example I've seen bite people is awaiting a request body.

What i'm saying is the only observable consequence of get() vs a hypothetical getOnlyIfItAlreadyExists is the creation of a record of where the DO is. If the DO is always being created in response to a user request, at 1 DO per user, then the DO is already in the "right" geographic location, or as well as we can do currently. So the existence of a record that you're not charged for, that is in a reasonable geographic location, is somehow problematic for you. What's the problem with it? What exactly do you think would change for you in this regard if you had getOnlyIfItAlreadyExists?

You still have to make 2 requests, unless you pull a ups.com and make people specify their location when they log in

If there is actually a difference for this use case, I'd like to understand it, but I don't

Like, the only thing I can come up with is being concerned about someone typoing an email address, that happens to correspond to a later user on the other side of the world

we're aware of that issue

but if there are any others, what are they?

That fact that you can be billed for a full request for looking up an object that doesn’t exist?

assume you'll be billed for a request regardless, because the info has to be obtained somehow

if you were running a business, would you provide people an infinite negative cache lookup for free?

point is you won't be billed for the record storing the DO location, because we intend to clean that up at some point in the future

and if that plan is not sufficient for people's needs, I'd really like to understand why

I’m not saying it has to be free, I’m just saying that I would assume that most of the cost of a DO fetch isn’t the DB lookup?

@ckoeninger Just to be sure to understood what you said. The current DO development state in CF is like this: If we call DO.idFromName(email), the 1st time it's require a global lookup, then this Name/ID is saved in cache of this colo. Next call (from this colo) we'll uses the cached association lookup and we'll run faster. Why not clone the lookup currently saved in cache to the other 285 PoPs? Kind of mini-KV lookup. With this, we doesn't have to try to open 2 DO to known if it's exists. We just have to do idFromName(email) again from anywhere in the world and we got the DO

assume it'll cost the same, what other concerns are there?

is latency the main thing you're concerned about? and you think getOnlyIfItAlreadyExists would be lower latency? the proactive replication rather than caching you're describing wouldn't seem to differentiate between get and GetOnlyIfItAlreadyExists

No I will give them a try today. Thanks

If a Worker in CPH asks whether a DO in SYD exists(and it is cached), it can return within a few 10s of milliseconds, rather than the 100+ required to actually travel to SYD

I'm concerned about starting (and paying) 2 DO (worldwide + eu) each time I need to known if a DO exists, but also the latency. We using CF because of the 285 PoPs and want to uses this advantages, but currently KV can't permit us to have this advantage (cold key < 60s), so I'm searching a faster central lookup to compensate

when you say cold key < 60s what exactly do you mean?

KV cold reads do not take 60 seconds

I think they mean hot reads when Cached

And how long it takes to update

I've asked few days ago on #874727019479437372 to known when a KV is cached in all the colo, and we answered me it's requiring a frequent access (more than 1 time per minute)

Using KV lookup in this sign up/sign in scenario will always require a 2nd KV request from the colo to one of the main central KV ( not sure the latency is better than just request our central DO in EU... at least for 90% of our visitors are in EU )

KV does not proactively replicate data to all colos, it uses the same cloudflare colo cache you have access to through the cache api in a read-through fashion