The Desi Architect
Notes / Docker Sandboxes / Cache Stampede, Mutex Locks & Single-Flight Request Coalescing
Docker Sandboxes · Tier 2: Data & Scale · Lab 30

Cache Stampede, Mutex Locks & Single-Flight Request Coalescing

Let a popular cache entry expire and send 40 clients at it together. Count the database queries, not guess them. See 40 queries without protection, 1 with single-flight in one server, 3 when you have three servers, and 1 again with a lock in Redis.

Time30 minutes
StackRedis 7Ports 16395, 15447
MemoryAbout 60 MB
Before thisLab 14Redis Cache-Aside Pattern, Invalid
Download lab (.zip) View steps
Verified runWindows, Mac, LinuxBash and PowerShell
  1. 1PrepareWhat you will learn
  2. 2PredictGuess before you run
  3. 3RunStep by step
  4. 4ObserveWhat you should see
  5. 5Break itChange one thing
  6. 6Clean upLeave nothing running
On this page
  1. 00 / What You Will Learn
  2. 01 / Why It Matters
  3. 02 / What We Are Building
  4. 03 / Words You Need
  5. 04 / Predict First
  6. 05 / Step by Step
  7. 06 / What You Should See
  8. 07 / Look Inside
  9. 08 / Break It, Fix It
  10. 09 / In Real Projects
  11. 10 / Interview Corner
  12. 11 / Clean Up

00 /What You Will Learn

By the end you will be able to
  • Explain a cache stampede and why a cache miss is dangerous for a popular key.
  • Explain single-flight and why it protects only one server.
  • Use SET key value NX PX as a simple shared lock, and say why it needs an expiry.
  • Name cheaper ways to avoid the stampede: jittered TTLs, early refresh, serving stale data.

Before you start

Finish Lab 14 (Redis Cache-Aside and Eviction) first. You should know a hit from a miss and what a TTL is. Docker Desktop and Python 3 are needed.