Cache Stampede Mitigation

A cache stampede begins simply: a high-traffic key expires, hundreds of concurrent requests arrive simultaneously, all encounter the same cache miss, and every single one attempts to regenerate the exact same value.

The cache store (such as Redis) may remain completely healthy, while the underlying database, external API, or downstream service absorbs an explosive burst of duplicated, expensive computation—the exact moment the cache was supposed to protect that dependency.

Caching vs. Coordination

This reveals the fundamental boundary where caching and concurrency coordination diverge: caching reduces computational work when there are hits, whereas coordination minimizes redundant work when hits vanish and multiple execution paths compete to recalculate the same state.

Single-flight mechanisms resolve this inside an application runtime by coalescing concurrent calls and allowing only one inflight computation per key. Across distributed instances, a lightweight distributed lock can coordinate worker nodes so that identical queries are not executed in parallel across the cluster.

Mitigation Strategies: Stale-While-Revalidate and Jitter

Stale-while-revalidate operates on a complementary principle: the system continues serving an expired value momentarily while an asynchronous background task refreshes the entry. This prevents every cache expiration from triggering a cascading wave of expensive misses.

Adding randomized jitter to TTL expirations further stabilizes the system by distributing expirations smoothly across time. This eliminates the synchronized thundering herd that occurs when thousands of keys created in batch expire simultaneously.

Beyond Hit Rate

These strategies do not replace a solid TTL policy; they answer a distinct architectural question: when cached data expires, which worker assumes the regeneration cost, and how are concurrent requests handled?

When computing an entry requires heavy SQL queries, network fan-out, or third-party service calls, relying solely on cache hit rate obscures the underlying vulnerability. True system resilience requires tracking how many executions repeat redundant work during each miss window.