A hot cache key expires and your database falls over. What happened, and how do you prevent it?

That is a cache stampede, sometimes called a thundering herd. Thousands of concurrent requests miss at the same instant and all recompute the same value. Fix it with single flight locking so only one worker recomputes while the others wait or serve stale data. Add jitter to TTLs so keys do not expire together, refresh hot keys in the background before expiry, and serve stale on error.

It is a stampede. The key expires, ten thousand in flight requests all miss simultaneously, and they all run the same expensive query, so the database sees ten thousand copies of a query it normally sees once a minute. The first fix is coalescing, so a single flight lock in the cache means one worker recomputes and everyone else waits on that result or gets the stale value. We used a Redis SETNX lock with a short TTL for this and database load on that path dropped by about two orders of magnitude. On top of that I add jitter to every TTL, so instead of exactly 300 seconds it is 300 plus or minus 10%, which decorrelates expiry across keys. For genuinely hot keys I prefer probabilistic early recomputation, where a request near the end of the TTL refreshes in the background while still serving the cached value. And I always cache negative results, otherwise a missing row becomes an unbounded query loop.