Cache stampede and the thundering herd

Redis Course · lesson 6 of 19 · 5 min read

One expired key can send every concurrent request for it to the database in the same millisecond.

Open this lesson in the learning hub

Key points

  • A stampede happens when a hot key expires and every in-flight request misses it at once and recomputes it.
  • The fix is to let one request rebuild: take a short lock with SET lock:key token NX EX 10 and let the losers wait or serve stale.
  • Serving stale is usually better than waiting: store the value with a logical expiry and refresh it in the background.
  • Probabilistic early expiry recomputes a key slightly before its TTL, so refreshes spread out instead of aligning.
  • Add jitter to every TTL, because keys created by the same deploy or warm-up job will otherwise expire together.
  • A cold restart is the same failure in a different costume: an empty cache sends 100 percent of traffic to the database.

Example

# one rebuilder, everyone else waits or serves stale
SET  lock:product:991 <token> NX EX 10
# -> OK    : you won, rebuild and SET product:991 ... EX 300
# -> (nil) : someone else is rebuilding, retry the GET shortly

# jitter, so 10k keys written together do not expire together
SET product:991 "{...}" EX 327   # 300 + rand(0,60)

One rebuilder, a leased lock, a stale value to serve meanwhile, and jitter on every TTL.

Cache-aside, write-through and invalidation Atomic operations and why INCR is not GET plus SET

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Redis Course course, and every lesson in it is listed on the Redis Course contents page.