Workers KV read-after-write: is 60 seconds the ceiling in practice, or just the documented number?
The docs say a KV write may take up to 60 seconds to be visible globally, and that a read in the same location as the write is usually immediate. I am trying to work out how defensively to design around that.
Our case: a Worker writes a short-lived session record on login and a subsequent request may land in a different colo within a second. We have seen a handful of misses — single digits per day out of ~40k logins — which is consistent with "eventual" but I cannot tell whether that is the expected tail or something we are doing wrong.
What I want to know from people running this in production:
- What propagation delay do you actually observe at p99? Is 60s a real number you have hit, or a conservative bound?
- Is
cacheTtlmaking this worse for us? We set 300 on the read, which I now suspect pins a negative result in the colo cache for five minutes. - Is the honest answer "use Durable Objects for anything read-after-write" and stop trying?
Happy to be told the last one. I would rather rewrite it than keep explaining a 0.02% failure rate.
Written by
Diego Alvarez
Platform and DevOps. I run our edge: Cloudflare Workers, KV, R2, and the CI that ships to them. Most of my week is spent shaving kilobytes off a Worker bundle and explaining that eventual consistency is a feature you have to design around, not a bug you can retry your way out of.
4 Comments
Sign in to join the discussion
That is almost certainly it. The read was copy-pasted from a config lookup where 300 is exactly right, and nobody asked whether it was right here.
For sessions specifically I think the honest answer is 'not KV'. It is a read-mostly cache with a write API, and you have a write-then-immediately-read workload. We moved everything with that shape to Durable Objects and stopped reasoning about propagation entirely, which was worth more than the latency we gave back.
60 seconds is a bound, not an observation, in the same way replication lag documentation quotes a worst case nobody sees weekly. But your
cacheTtl: 300is doing real damage: a miss gets cached in that colo for five minutes, so one unlucky read pins the failure long past the propagation window. Drop the TTL on that specific read and I would expect most of your single-digit misses to go with it.