Exercise — Cache Stampedes and Stale Data

What you'll walk away with

Explain the core ideas behind Exercise — Cache Stampedes and Stale Data
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

When popular keys expire together, many requests can stampede the database. Combine TTL jitter, request coalescing, short locks, stale-while-revalidate, and prewarming according to workload. Stale serving needs a maximum-staleness bound and explicit safety exclusions.

Connect it to a real scenario

Scenario: a homepage key has a 300-second TTL, traffic is 20k RPS, database capacity is 500 QPS, and all keys are cold after deployment. Design recovery with fresh and stale values, lock timeout, jitter, DB circuit breaker, rollout prewarming, and metrics.

Avoid synchronized expiry
Use one loader and bounded stale data
Protect and observe the database

Try the working example

text

Given: 20,000 RPS, DB capacity 500 QPS
Design: TTL = 300s + random(0..60s)
Lock: SET cache:home:lock <token> NX PX 3000
Stale limit: 10 minutes
Measure: hit_rate, stale_served, lock_wait, db_qps, p99_latency

You should see

The design keeps DB load within capacity while bounding freshness during spikes.

5-minute try-it

Produce a sequence diagram, failure table, and load-test acceptance criteria.

One important caution

Do not serve stale authorization, price, or inventory data without explicit business approval.

Redis — Distributed Locks — Redis

Easy traps

Do not serve stale authorization, price, or inventory data without explicit business approval.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Produce a sequence diagram, failure table, and load-test acceptance criteria.

You'll know it worked when: The design keeps DB load within capacity while bounding freshness during spikes.