Redis Cache Stampede Prevention Design Prompt
Design defenses against cache stampede (dogpile/thundering herd) when a hot Redis key expires and many clients recompute it at once — locks, early recompute, and jittered TTLs.
- Target user
- Backend engineers and SREs hardening read-heavy caches
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior backend engineer who designs cache-stampede defenses for high-QPS Redis caches. I will provide: - The read QPS on the hot key(s) and the cost/latency of recomputing the value (DB query, API call) - Current TTL strategy and how misses are handled - Whether stale-while-revalidate is acceptable for this data Your job: 1. **Name the failure**: when a hot key expires, every concurrent reader misses simultaneously and stampedes the backing store. Explain how this shows up (a latency cliff and a DB/CPU spike every TTL interval). 2. **Choose a mitigation** (usually several): - **Mutex / lock-on-miss**: first miss acquires a short-lived lock (`SET lock:key token NX PX 5000`), recomputes, and repopulates; others briefly serve stale or wait+retry. Release with a Lua compare-and-delete so you never delete another holder's lock. - **Early / probabilistic recompute (XFetch)**: refresh *before* expiry with probability that rises as TTL approaches, so recompute happens off the cliff. - **TTL jitter**: add randomised jitter to every TTL so keys written together don't all expire in the same second. - **Stale-while-revalidate**: serve the last value past its logical expiry while one worker refreshes in the background. - **Request coalescing** at the app layer so duplicate in-flight computes collapse to one. 3. **Guard the lock**: bound the lock TTL so a crashed holder can't wedge the key; define the wait/retry and fallback-to-stale path. 4. **Pick per-key vs global**: only the genuinely hot keys need this; don't lock everything. 5. **Define signals**: `keyspace_misses` spikes, backing-store QPS synchronised to TTL boundaries, p99 sawtooth. Mark DESTRUCTIVE or risky: unbounded lock TTLs (a dead holder blocks the key forever), `DEL` of a lock you may not own (delete the wrong holder's lock → double compute), and serving stale data where correctness forbids it. --- Hot key + QPS: [DESCRIBE] Recompute cost/latency: [DESCRIBE] Stale acceptable?: [YES/NO]
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Cache stampede is invisible until a hot key expires and the backing store takes a synchronised hit every TTL interval. This prompt forces the two decisions that actually matter — how the first miss is serialised (lock vs early recompute) and whether stale data is acceptable — and it insists on a lock design that can’t wedge the key or delete the wrong holder.
How to use it
- Identify the genuinely hot keys — stampede defenses cost complexity; apply them only where QPS × recompute-cost is high.
- State the recompute cost — a 5 ms cache fill rarely needs a lock; a 2 s aggregation does.
- Decide on staleness up front — it unlocks the simplest and most robust option (stale-while-revalidate).
Useful commands
# Miss rate and hit ratio over time
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'
# Acquire a bounded lock on miss (NX = only if absent, PX = auto-expire)
redis-cli SET lock:report:daily $(uuidgen) NX PX 5000
# Inspect remaining TTL to drive early recompute
redis-cli PTTL report:dailyExample lock release (Lua compare-and-delete)
-- KEYS[1]=lock key, ARGV[1]=our token
if redis.call('GET', KEYS[1]) == ARGV[1] then
return redis.call('DEL', KEYS[1])
else
return 0
endCommon findings this catches
- No jitter → thousands of keys expire in the same second.
- Unbounded lock TTL → a crashed worker freezes the hot key.
- Blind
DELof the lock → one worker deletes another’s lock, causing double compute. - Locking every key → needless latency on cold keys.
- No stale fallback → clients block instead of serving the last good value.
When to escalate
- The recompute itself is the bottleneck — cache stampede defenses only smooth the miss, not a slow query.
- The hot key is genuinely hotter than one node can serve — consider read replicas or client-side caching.
Related prompts
-
Redis Cache Invalidation Strategy Design Prompt
Design a correct cache-invalidation strategy for Redis — write-through vs write-behind vs cache-aside, versioned keys, and event-driven busting — so stale reads never outlive the source of truth.
-
Redis Fork and Copy-on-Write Latency Tuning Prompt
Diagnose and tune Redis fork/copy-on-write latency during RDB and AOF rewrites — THP, overcommit, latest_fork_usec, and COW memory — so background saves stop stalling the primary.
-
Redis Big Key and Hot Key Analysis Prompt
Hunt down oversized keys and traffic-skewed hot keys that cause latency spikes, uneven cluster load, and blocking deletes — then fix them safely.
-
Redis Client-Side Caching (Tracking) Design Prompt
Design a RESP3 client-side caching layer with server-assisted invalidation — default vs broadcast tracking, BCAST prefixes, OPTIN/OPTOUT — without serving stale data.
More Redis prompts & error guides
Browse every Redis prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.