Redis Cache Collapse Under Stampede
A cache key (or key namespace) expires or is evicted simultaneously for many users. Thousands of requests hit the database to recompute the same value: a cache stampede. The database becomes overwhelmed, latency spikes, and the cache fills too slowly to absorb the flood, causing a self-reinforcing collapse loop.
Redis cache layer + PostgreSQL primary + application server pool
Degradation Replay
Nominal: Cache Warm
All hot keys cached; cache hit rate > 95%
Critical: 97 exceeds critical threshold of 60 %
- ·Cache hit rate 95-99%: near-zero DB reads for cached paths
- ·Response latency driven by Redis RTT (~1ms)
- ·Redis serving majority of read traffic
- ·PostgreSQL only sees writes and uncached reads
- !Normal operation: users see fast responses
Operational simulation model only, not a production forecast. Degradation stages are derived from structured operational knowledge, not measured telemetry. Do not use for capacity planning or incident response.
Run With Your Parameters
Adjust the parameters below to see how metric values shift across degradation stages. Formulas are deterministic: same inputs always produce the same output.
Simulation Parameters
Steady-state request rate
Peak traffic as a multiple of baseline
Total Redis memory allocated to the cache
Hot data size accessed at peak load
Computed Degradation Stages
All hot keys cached; cache hit rate > 95%
Hot cache key expires; first wave of concurrent misses hits DB
DB slow under load; slow response delays cache repopulation; collapse self-reinforces
DB query completes; first value written to cache; hit rate begins recovering
Threshold Events
Cache hit rate at 0%: working set (800 MB) exceeds cache (512 MB) under 0.4× peak load.
DB connection pool at 100%: cache misses driving database load. Miss rate: 6000 req/s against a 100-connection pool.
Interpretation
At 3.0× peak with 512 MB cache and 800 MB working set, cache hit rate collapses to 0%. DB connection pool reaches 100%.
Cache working set exceeds capacity → stampede → DB overload
Increase cache to 1040 MB to absorb full working set at peak. Add probabilistic early expiry (PER) or mutex-based single-flight to prevent stampede. Implement stale-while-revalidate to serve slightly stale data during repopulation.
Parameterized simulation: not a production forecast. Values derived from deterministic formulas applied to your parameters. Do not use for capacity planning or operational decisions without validation.
Propagation Model
Each cache miss triggers a DB query; concurrent misses for same key produce N identical DB queries: thundering herd
Stabilizes: First DB response populates cache; subsequent requests hit cache again
DB under pressure responds slowly; slow response delays cache repopulation; more misses accumulate
Stabilizes: Cache repopulates once DB pressure subsides: but requires DB to recover first
Requests waiting on DB exhaust connection pool; new requests queue or error
Stabilizes: Connection pool drains once DB queries resolve
Recovery Patterns
Manual cache pre-warm
1-5 minutes with scripted warm-up- ·Requires ops runbook and access to a known-good data source
- ·Pre-warm data may be slightly stale: acceptable during incident
- !If trigger was memory pressure, pre-warm may be evicted again immediately
Self-healing via DB query completion
30-120 seconds for hot keys to repopulate- ·DB must survive the stampede flood: may require traffic throttling
- !If DB is overwhelmed and cannot respond, cache never repopulates: deadlock
Operational Summary
Cache stampedes occur when many concurrent requests miss the same expired key simultaneously. The thundering herd amplifies DB load N-fold (N = concurrency). The critical failure mode is a self-reinforcing collapse: DB pressure slows cache repopulation, which keeps hit rate low, which sustains DB pressure. Prevention requires TTL jitter, stale-while-revalidate, or request coalescing (mutex).