About workers kv concurrency limit for writing the same key

I am curious about the limitation of up to writing the same key one time per second. As I know Workers KV has two data centers, then how to coordiate them to ensure the same key can not be written at the same time at different centers?

The last write wins. If it’s updated at two different colos the one which wrote it last will be the one used.

Thanks for your reply.
I found k-v will return success after updating at one data center, no need for updating at another data center. So I think there may be some problems. If I update the same key in German and in States at the same time, they will both return success after writing on the nearest data center. The updated k-v pair, in the process of spreading to another data center, should have some problems? like overwriting each other? If they have timestamp mechanism to keep newer request get handled, how can they ensure there is no timestamp difference.

Workers KV is distributed and eventually consistent, so race conditions can definitely happen as you’ve described. If you need immediate consistency, you should take a look at Durable Objects. They only “live” in a single location at once, which is how they can guarantee consistency, but it means they can be slower than KV in some situations.

I see, but in that case, will there be inconsistency in different data centers? That’s bad.

There can be temporary inconsistency, but typically only for a minute or so. That’s not a problem for many applications, but if you need real-time consistency, as albert said, you can use Durable Objects.