---
title: '4 Ways to Fix Cache Stampede'
source: 'https://youtube.com/watch?v=MPFkGLZGe9M'
video_id: 'MPFkGLZGe9M'
date: 2026-08-04
duration_sec: 104
---

# 4 Ways to Fix Cache Stampede

> Source: [4 Ways to Fix Cache Stampede](https://youtube.com/watch?v=MPFkGLZGe9M)

## Summary

The video discusses the cache stampede problem, where many requests hit a database simultaneously after a cache entry expires. It presents four strategies to mitigate this issue: cache locking, request coalescing, probabilistic early refresh, and background refresh, each with its own trade-offs.

### Key Points

- **Cache Stampede Problem** [00:02] — When many requests hit the database at once after a cache miss, it's called a cache stampede. Most engineers only know one way to fix it, but there are four approaches.
- **Cache Locking** [00:15] — A lock allows one request to rebuild the cache while others wait. Simple to implement, but if the rebuild is slow or fails, requests may time out.
- **Request Coalescing** [00:31] — Duplicate in-flight requests are folded into one upstream call, and all get the same result. Cloudflare does this at the CDN layer, so even a million users hitting the same key results in at most one request per app server.
- **Probabilistic Early Refresh** [00:44] — As a cache entry ages toward its TTL, each request has a small but growing chance of triggering a background refresh. For example, at minute 50 of a 60-minute TTL, about 1% of requests refresh; at minute 59, about 20%. This spreads the refresh naturally.
- **Background Refresh** [01:11] — A dedicated worker proactively recomputes hot keys before they expire, eliminating stampede risk. The trade-off is needing to know what's hot ahead of time. Ticketmaster event pages are a perfect fit, but random traffic spikes are not.
- **Recommendation** [01:26] — Start with request coalescing as it's the easiest win and works at the CDN or app layer with no TTL changes. Add probabilistic early refresh for unpredictable spikes, and use background refresh for known hot keys.

### Conclusion

The video provides a concise overview of four cache stampede mitigation techniques, recommending a layered approach starting with request coalescing and adding probabilistic or background refresh based on traffic predictability.

## Transcript

requests hit your database at once. That's a cash stampede and most engineers only know one way to fix it. Let's go through four approaches. First, Let's go through four approaches. First, cash locking. A lock lets one request
rebuild the cash while everyone else waits in line. Simple to implement, in your system. The downside of this is that if the rebuild is slow or fails, are going to be timing out. Another approach is to collapse requests instead
of queuing them. Every duplicate in-flight request gets folded into one upstream call and everyone gets the same result back. Cloudflare does this at the CDN layer. Even if a million users hit the same key, your back-end sees at most
one request per app server. We can also rely on randomness. As a cash entry ages rely on randomness. As a cash entry ages toward its TTL, each request has a small but growing chance of triggering a background refresh. So, at minute 50 of
background refresh. So, at minute 50 of a 60-minute TTL, maybe 1% of requests refresh it. At minute 59, maybe 20%. Refresh is spread out naturally. The last is a background refresh. A dedicated worker proactively recomputes
hot keys before they expire. This means zero stampede risk. The trade-off is you need to know what's hot ahead of time. Ticketmaster event pages are a perfect fit, but random traffic spikes are not. So, start with request coalescing. It's
the easiest win and works at the CDN or app layer with no TTL changes. You can add a probabilistic early refresh for unpredictable spikes. Use background demand. Like and follow us for more system design tips.
