Concept
Cache Stampede & TTL Jitter
The Cache Stampede Problem
A cache stampede occurs when a popular cached item expires and thousands of concurrent requests simultaneously miss, all racing to rebuild the data from the database. The database, suddenly receiving a massive spike of identical queries, may crash — an ironic failure caused by the system designed to protect it.
TTL Strategy: Setting the Right Expiry
| Data Type | Staleness Tolerance | Recommended TTL |
|---|---|---|
| Real-time critical (prices, inventory) | None | Don't cache, or Write-Invalidate + TTL ≤ 10s |
| Frequently updated, non-critical | Seconds to a minute | Short TTL (5–60s) + Write-Invalidate |
| Infrequently updated, important | Minutes to an hour | Medium TTL (5–60 min) + Write-Invalidate |
| Static or semi-static | Hours to days | Long TTL (1–24 hrs) |
| Configuration / system data | Very high | Infinite TTL + explicit invalidation on change |
TTL Jitter — Preventing Thundering Herd at the Source
If many popular items share the same TTL, they expire simultaneously. The resulting mass of cache misses slams the database. The fix: add randomness to every TTL.
Instead of ttl = 300, use ttl = 300 + random(-30, 30).
This staggers expirations over a time window, smoothing database load at zero performance cost. Apply this to every frequently accessed cached item as a default.