The most dangerous moment in caching is expiry of something popular: ten thousand concurrent requests, one stale object, and an origin that is about to learn how many edges you have. Request coalescing is the machinery that makes that moment a non-event, and its quality varies more than buyers assume.
The mechanism, precisely
When a cacheable object misses or expires under concurrency, a coalescing cache elects one request to fetch upstream and parks the rest in a wait queue; the single response then fans out to every waiter. The origin sees one fetch. Without coalescing, it sees all of them, the thundering herd, and hot-object expiry becomes a synchronized load spike shaped exactly like your popularity curve.
The design details that differ
Implementations diverge on the edges: how long waiters queue before timing out, whether they can be served stale while waiting (coalescing plus stale-while-revalidate is the gold pairing), whether coalescing spans just one node, a whole POP, or the shield tier, and how uncacheable-response discoveries release the queue. Layer-wide coalescing at the shield is what collapses a global stampede into literally one origin request; node-local coalescing merely dampens it.
This machinery has a famous failure genre worth studying: cache stampede incidents, where a deploy, a mass purge or a synchronized TTL boundary expired swaths of hot content at once and the resulting herd flattened origins that had been comfortably idle minutes earlier. The mitigations are all boring and all effective: TTL jitter so expiries desynchronize, soft purges that mark stale instead of deleting, staged invalidations, and coalescing verified at the shield. Estates that adopt all four convert their scariest traffic events into log entries, which is the correct destiny for infrastructure drama.
The pathological cases
Slow origins turn wait queues into latency cliffs: a two-second origin fetch means two-second waits for every coalesced user unless stale-serving rescues them. Objects that oscillate between cacheable and not (cookie leaks, header drift) defeat coalescing intermittently and confusingly. And per-user-varied content coalesces by cache key, so fragmented keys (our Vary article) quietly disable the protection exactly where traffic concentrates.
In practice
Test it deliberately in staging: expire a hot object under synthetic concurrency and count origin arrivals; the answer should be one per layer, ideally one total. Pair every short-TTL hot path with stale-while-revalidate so queues drain instantly. And when evaluating providers, ask at which layer coalescing operates and what the waiter policy is, questions that reliably distinguish teams who have operated large caches from teams who have documented them.
Our resilience reviews include a stampede tabletop against your actual purge and deploy patterns. It finds things.