Cache Stampede: What It Is and How to Prevent It

A cache stampede happens when a popular cache entry expires and many concurrent requests all miss simultaneously, all query the database, and all try to write the same key back — which can take a database from healthy to overloaded in seconds.

Why it happens

• At steady state, the cache serves thousands of requests per second for a popular entry; when that entry's TTL expires, all those concurrent requests reach the database simultaneously — the database receives the full request rate for that entry directly
• If the database query is expensive (joining multiple tables, scanning millions of rows), all concurrent threads run it simultaneously; the database CPU saturates, latency spikes, and the storm persists until the cache is repopulated

Prevention 1 — Mutex lock

• When the cache misses, acquire a distributed lock before querying the database: redisTemplate.execute(new RedisCallback<> { ... SET nx EX 10 ... }); only the thread that acquires the lock queries the database; all other threads wait briefly and then read from the now-populated cache
• The downside: threads that miss the lock must wait; set the lock TTL longer than the database query duration; handle the case where the lock holder fails before populating the cache

Prevention 2 — Probabilistic early expiry

• Rather than expiring all at once, each request has a small probability of proactively refreshing the cache before expiry — as the TTL decreases, the probability of early refresh increases
• By the time the cache actually expires, a lucky early request has already refreshed it; expiry never causes a synchronized miss because the value is always refreshed before TTL reaches zero

Prevention 3 — Background refresh

• A scheduled background job refreshes cache entries before they expire — user-facing requests always hit a warm cache because expiry happens in the background, not in the request path
• This is the cleanest solution for high-traffic hot keys: the cache is perpetually warm, and the database is queried once per TTL period regardless of traffic volume

Prevention 4 — TTL jitter

• If many keys expire at the same time (set at startup with the same TTL), they all stampede together; add a random jitter: TTL = baseTTL + random(0, baseTTL * 0.2) distributes expiry across a window