Who pays: push or pull

Does each caching mechanism bill the writer or the reader?

The cleanest way to choose between mechanisms is push versus pull. Write-through and invalidation broadcast are push: they bill the writer. TTL and revalidation are pull: they bill the reader. The direction you choose is the choice of who pays. Write-back sits where durability meets acknowledgment latency, which is why it belongs partly to the field of durability. Explicit invalidation couples every writer to the cache topology (every writer must know where the caches are).

Case, resolvedConstructed case · Ifeoma at Dawnpost

The 09:00 stampede and the missing correction

At 09:00, 3,000 requests recomputed the expired homepage entry at once, an editor reloaded and did not see her correction, and a half-failed write left cache and database disagreeing for good. Where it started: Keeping it honest →

The 09:00 stampede. L = λ_k · W = 1,500 × 2 s = 3,000 duplicate queries. Ifeoma adds three things. Each node coalesces requests for the same key, so each node runs one query. The homepage entry gets early probabilistic expiry, scaled by its measured 2-second recompute time, so one request refreshes it a few seconds before 09:00 while the old copy is still served. And every TTL in the article cache gets jitter of ±10%, so the million entries filled by the morning deploy no longer expire together.

The editor's missing correction. Her page reads from a cache entry that the editor's save did not touch, because the save path wrote to Postgres only. Ifeoma changes the save path to write the store first and then delete the cache key, and she puts a version token in the editor's session. The editor's next read includes that token in the key, so a cache that has not caught up simply misses and reads Postgres. That is read-your-writes without sticky routing.

The disagreement after a failed update. The old code updated the cache after the database write. When the cache write was lost, or when two saves raced, the cache kept the wrong value. With delete there is nothing wrong to keep: the next read refills from the store. And a 10-minute TTL (with jitter) is the floor under the case where a delete message is lost, or a reader refills the cache with an old value just after the delete.