Cache Stampede: Beat the Thundering Herd in Redis

It is 9:03 a.m. A marketing email just went out to two million users. They all click the same link, and your homepage tries to load the same hot cache key at the same instant. The key happens to expire at 9:03 a.m. In the next 50 milliseconds, forty thousand requests miss the cache, decide the value is stale, and slam your database with the identical expensive query. The database’s connection pool saturates, query latency climbs from 8 ms to 8 seconds, healthy requests start timing out, and your retry logic doubles the load. By 9:04 a.m. the site is down — not because traffic was unmanageable, but because a single expired key turned a cache into a stampede.

This is the cache stampede (also called the thundering herd or dog-piling), and it is one of the most common ways a perfectly healthy system falls over under load it should easily absorb. The dangerous part is that it is invisible in normal operation: your cache hit rate is 99.9%, dashboards are green, and everything looks fine… right up until one popular key expires under concurrency. This guide walks through why it happens, three production-grade fixes — distributed locking, single-flight request coalescing, and probabilistic early expiration — and exactly when to reach for each. By the end you will be able to design a cache layer that degrades gracefully instead of collapsing.