What is a cache stampede — and how a cache can take down your database

You added a cache, and the site could breathe again. The home page is built from a heavy two-second database query. Now the result sits in the cache for an hour, and the page opens instantly.

For 59 minutes everything is perfect. At minute 60 the key expires. And in that same second, 300 people open the home page.

Each of them sees: the cache is empty. Each goes to the database for the same two-second query. The database gets 300 heavy queries at once and falls over. The site goes down — and it goes down because of the cache you added so it wouldn't.

This has a name: cache stampede.

What is a cache stampede, in plain words

A cache stampede is when a popular cache entry disappears and many requests rush to recompute the same thing at the same time.

Normally a cache works like a person on duty: the first one in does the work, everyone else takes the result. The trouble is the word “first.” While the first one is still computing, the cache is empty. And everyone who arrives during those two seconds also thinks they're first.

The more popular the key and the longer the recompute, the bigger the crowd. A key read once a minute never causes a stampede. A home page under load always will.

Why it's sneaky

While traffic is low, there's no problem at all. You won't see it locally or catch it in a test. It shows up exactly when your app gets popular. In other words, at the worst possible moment.

And it has an amplifier. After a restart, all keys are created at almost the same time. If they all live exactly 3600 seconds, they'll all expire at almost the same time too. An hour later, the database gets not one stampede but all of them.

This mechanism can take down a giant. In 2010 Facebook was down for about two and a half hours. A configuration value was written to storage that the system treated as invalid. Every server saw the “bad” value in the cache, threw it away, and went to the database for the right one. Hundreds of thousands of queries per second. Database errors only made it worse: on each error, clients deleted the value again and went back for it. They had to turn off the whole site to make the crowd disperse.

Three ways to avoid a stampede

1. Let only one compute. The first request leaves a note saying “I'm recomputing” — a lock in Redis or a flag in memory. The others don't go to the database; they wait a couple hundred milliseconds and check the cache again. Inside a single Node process it's even simpler: store not the result but the recompute promise itself. Everyone who arrives waits on the same promise.

const inFlight = new Map()

async function getHome() {
  const cached = await cache.get("home")
  if (cached) return cached
  if (!inFlight.has("home")) {
    inFlight.set("home", buildHome().finally(() => inFlight.delete("home")))
  }
  return inFlight.get("home") // all 300 wait on one database query
}

2. Serve the old while the new is cooking. This is called stale-while-revalidate. The key has “expired” but isn't deleted. The user instantly gets yesterday's version, and a single refresh runs in the background. For a home page, data a minute old is fine. A page that won't open isn't. CDNs do the same trick, and so does the HTTP header Cache-Control: stale-while-revalidate=60.

3. Spread the expiry. Don't give every key exactly one hour. Give it an hour plus a random 0–5 minutes. Keys created together will expire at scattered times, and the database gets a steady trickle instead of a tsunami. There's a cleverer variant too — refreshing a key a little early with some probability. It's described in a 2015 paper with the very direct title “Optimal Probabilistic Cache Stampede Prevention.”

How to tell it's your problem

Look at your database load graph. A flat line with sharp spikes at regular intervals is almost always a stampede. Especially if the interval matches your cache lifetime: an hour, five minutes, a day. If AI wrote your caching code, check it for one thing. What happens when two requests see an empty cache at the same time? If the answer is “both go to the database,” add one of the three fixes above.

Is cache stampede the same as thundering herd?

Almost. Thundering herd is the general term: many participants rush one resource at once. A cache stampede is a special case, where the crowd is released by an expired cache key.

Does a small project need this?

While you have a dozen visitors an hour, there won't be a stampede. But spreading the expiry costs one line. Add it now — and you won't have to remember it the day your post goes viral.

Can I just make the cache permanent?

Then users will see stale data until you clear the cache by hand. And a manual clear is the same stampede, just on your command. A permanent cache works for things that never change, like images with a hash in the file name.