Burst Traffic Cold Cache Stampede
After a deployment or Redis restart, a sudden burst of traffic hits the origin with a fully cold cache. Every request misses and simultaneously hammers the database. Unlike a gradual cache miss, a cold-start stampede compresses all miss load into a single second: the database sees its entire warm-state load in one instant, with no ramp-up time to absorb the flood.
Redis cache cluster + PostgreSQL primary + load-balanced application server pool
Degradation Replay
Nominal: Cache Warm, Traffic Stable
Cache populated with all hot keys; traffic at expected baseline
Critical: 95 exceeds critical threshold of 40 %
- ·Cache hit rate 92-98%
- ·Database receiving 80-200 QPS from cache miss traffic only
- ·P99 response time under 20ms (Redis RTT dominant)
- ·Database connection pool at 10-15% utilization
- ·Redis serving 95%+ of read traffic: database protected behind cache
- ·Deployment or restart event will wipe this state entirely
- !System operating at full efficiency: cache absorbing majority of read load
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
Computed Degradation Stages
Cache populated with all hot keys; traffic at expected baseline
Redis restart or deployment completes; traffic arrives against empty cache
Database connection pool 70%+ utilized; query queue forming; latency exceeds 1 second
Connection pool fully exhausted; requests queuing in application; error rate >5%
Cache hit rate recovering above 40%; database query rate falling; connection pool pressure releasing
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
Cache pressure with 512 MB cache vs 800 MB working set at 3.0× peak. Hit rate drops to 0% under load.
Insufficient cache relative to working set size
Size cache to at least 960 MB. Add TTL jitter to stagger expiry events. Monitor eviction rate: non-zero eviction under load means cache is undersized.
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
100% cache miss rate means every incoming request issues a database read; at 500 RPS, database receives 500 concurrent read queries in the first second: orders of magnitude above warm-state baseline
Stabilizes: Stabilizes as cache repopulates: first requests to complete repopulate keys, subsequent requests hit cache again
Database under pressure responds slowly; slow responses delay cache SET operations; slow repopulation sustains high miss rate; sustained high miss rate sustains database overload
Stabilizes: Loop breaks when database pressure subsides enough for first responses to complete and populate cache
All application threads blocked waiting for database responses; new incoming requests queue or receive 503 errors when queue depth is exceeded
Stabilizes: Connection pool frees as queries complete; error rate drops once cache hit rate exceeds 50%
Recovery Patterns
Pre-warm cache before traffic switch
Zero incident duration: requires 5-10 minutes warm-up before deploy- ·Warm-up script must accurately simulate real access patterns: cold path coverage matters
- ·Warmed cache in new deployment may contain stale data if populated pre-deploy
- !Traffic patterns may not match warm-up script: some keys will still be cold on first access
Request coalescing (single-flight pattern)
Recovers within 30-60 seconds: reduces duplicate database load by 90%+- ·Requires application-level implementation: not available in all frameworks by default
- ·First request for each key still hits database: just eliminates N-1 duplicate requests
- !Cold-start still causes elevated database load: just reduced proportionally to unique key count
Operational Summary
Cold-cache stampedes are a predictable, preventable incident class that gets triggered by deployments and Redis restarts. The problem is not the missing data: it's the thundering herd of concurrent requests all demanding the same data simultaneously, before the cache has had any time to repopulate.
The self-reinforcing feedback loop is the dangerous part: the database slows under pressure, slow database responses delay cache population, delayed population sustains high miss rate, high miss rate sustains database pressure. This loop can sustain for 5-15 minutes without intervention: long enough to cause an incident.
Prevention is inexpensive: a cache warm-up script run before traffic switches, and request coalescing to prevent N concurrent requests from all hitting the database for the same key. These two measures together make cold-start stampedes essentially non-incidents.