Cache stampede (also known as dog-piling or cache miss storm) is a phenomenon where multiple concurrent requests for the same piece of data all miss the cache simultaneously due to expiration, overwhelming the backend database with redundant queries.

Cache stampede, also referred to as dog-piling or cache miss storm, is a common performance anti-pattern in caching systems. It occurs when a cached item expires (or is invalidated) and a large number of concurrent requests for that same item all miss the cache at the same time. This causes every request to hit the backend database or origin server simultaneously, leading to a massive spike in load that can overwhelm the system, cause high latency, or even trigger a cascading failure.

How Cache Stampede Happens

Prevention Strategies

1
Stale-While-Revalidate (SWR): Serve stale cached data while asynchronously refreshing the cache in the background. The first request after expiry triggers a refresh, but subsequent requests receive the stale data (not a miss). This is implemented in Next.js ISR and many CDNs.
2
Request Coalescing (Request Deduplication): When a cache miss occurs, only the first request goes to the backend; subsequent identical requests wait for the first request's result. Implement using a mutex or a promise cache (e.g., p-limit, async-mutex, or a simple Map of in-flight promises).
3
Probabilistic Early Expiration (PEE): Instead of letting all cached items expire at exactly the same time, a small percentage of requests are allowed to refresh the cache early (e.g., when the TTL is 90% expired), preventing a stampede at 100% expiry.
4
Jittered Expiration: Add random variation to cache expiration times (TTL = baseTTL + random(0, jitter)), preventing multiple keys from expiring simultaneously.
5
Locking (Mutex): Acquire a lock on the cache key when a miss occurs. Only the request holding the lock can regenerate the cache; others wait or receive stale data.

Request Coalescing Implementation (Node.js)

How Next.js Handles Cache Stampede

1
ISR with stale-while-revalidate: Next.js automatically implements the stale-while-revalidate pattern. When a page's revalidate time is reached, the first request triggers background regeneration, but subsequent requests receive the stale (cached) page, not a cache miss.
2
fetch Deduplication: Next.js automatically deduplicates identical fetch requests that occur within the same render pass, preventing redundant network calls.
3
Data Cache with Tags: On-demand revalidation (revalidateTag/revalidatePath) provides granular invalidation, preventing mass cache expiry stampedes by updating only affected data.

Difficulty: 5/10

Topics: cache stampede, redis, thundering herd

Scenario Questions

0-2 years experience

1
Our service uses Redis to cache product details. If the cache entry expires and a sudden burst of users request the same product, what could go wrong and how would you prevent it?
2
You notice the backend API latency spikes every time a cache key expires. Which simple Redis pattern could you add to avoid that spike?

2-5 years experience

1
During a rollout you see a thundering herd on a hot endpoint after a cache miss. Walk me through how you would debug the issue and which Redis‑based fix you would implement.
2
We want to add a cache‑aside layer for user sessions, but we’re worried about stampedes when sessions expire. Which trade‑offs would you consider between using a lock versus a probabilistic TTL bump?

5-8 years experience

1
Design a resilient caching strategy for a high‑traffic news feed that must stay fresh while avoiding cache miss storms. Include Redis primitives, fallback paths, and monitoring.
2
Our microservice cluster experiences occasional cache stampedes that crash the database. Explain how you would redesign the cache‑population logic to be safe at scale, and discuss the performance impact of each option.

8+ years experience

1
At a company‑wide level you need to standardize cache‑stampede protection across dozens of services using Redis. What architectural guidelines would you set, and how would you handle legacy services that cannot be changed quickly?
2
Imagine you are migrating from an in‑process memory cache to a shared Redis cluster. How would you ensure that existing stampede‑prone patterns are eliminated without causing downtime or data inconsistency?

Follow-up Questions

❓How would you measure whether your mitigation is actually reducing load spikes?
❓What impact does adding a lock have on request latency under normal traffic?
❓Can you think of a scenario where probabilistic expiration might cause stale data issues?