Cache Warming

The Cold-Start Problem

 empty cache = 100% miss rate:

 [deploy/restart/failover] ──► cache empty
    ──► every read hits db at FULL traffic rate
    ──► exactly the stampede/breakdown scenario, scheduled

 the danger window: until hit rate rebuilds naturally —
 minutes to hours depending on working set vs traffic.

What to Warm and How to Know

 warming everything is impossible (that's what caching was for).
 warm the HEAD of the distribution:

 - analytics/top-K: most-read entities in last 24h/7d
   (redis LFU sampling or your metrics already know)
 - critical-path keys: homepage payloads, config, feature flags
 - auth/session data if sessions live here (MUST-warm class)

 keep a WARM MANIFEST: periodic snapshot of top-N keys
 (ids only; values refilled from source) — cheap insurance.

Warming Strategies

Strategy	Mechanism	Fit
Pre-boot preload	Pod warms before health-check passes	Planned deploys
Background filler	Async job walks manifest continuously	Always-on top-up
Traffic ramp	LB sends 5%→25%→100% while cache fills	Big restarts
Shadow fill	New cache populated by mirrored reads	Cache replacement

 pre-boot pattern (most common):
   pod starts → load manifest top 10k keys (parallel, throttled)
   → mark ready → receive traffic
 converts a cold start into a ~30s delay instead of an incident.

Throttle the Warm Itself

 naive "load everything now" = self-inflicted stampede:

 - parallelism cap:      ≤ 20 concurrent source fetches per pod
 - jitter between pods:  don't let all replicas warm simultaneously;
                         stagger by minutes
 - off-peak scheduling:  planned restarts during traffic valleys
 - circuit-break the warmer if source latency degrades

 the warmer is a client like any other; give it manners.

Scheduled Events Need Scheduled Warmth

 predictable spikes (sales, ticket drops, game launches):

 t-60min: scale cache fleet up
 t-45min: warm known hot entities (event catalog, seating maps)
 t-15min: verify hit rates ≥ target on synthetic probes
 t-0:     doors open onto a HOT cache

 same playbook as capacity planning but for freshness:
 warmth is provisioned, not hoped for.

Measuring Recovery

 after any cold event, watch:
 - hit rate curve: should climb steeply then plateau
 - db qps: mirror-inverse of hit rate
 - time-to-steady-state: your real recovery SLA
 
 alert if hit rate hasn't recovered within expected window —
 a stuck-cold cache looks like "slow db" to everyone else;
 make it visible as what it is.

Interview Framing

“Deploy requires restarting Redis — safe?” expects the full arc: no (breakdown risk), warm-manifest concept, pre-boot warming with pod-level readiness gating, throttled+staggered refill, ramped traffic cutover, and post-event hit-rate monitoring. Warming questions test whether candidates think about cache LIFECYCLE, not just steady state.