Contain a cache stampede

You own a product-description API. Most reads come from a shared cache, but one popular product expires at peak traffic. Several API instances can receive requests for that same product at once. Protect the source while preserving the display's freshness contract.

Use the fictional workload below. Calculate normal and cold-cache source demand, predict the hot-key burst, then write a refresh timeline and failure policy. You do not need to choose a cache vendor or design an entire commerce platform.

Allow two minutes for the brief, eight for your attempt, five for comparison, and five for revision. There is no countdown. A statement of uncertainty is a valid first attempt; the optional hints can help you find the next step.

Incoming traffic

10,000 description reads/second at the modeled peak.

Normal cache hits

95%. Each uncoalesced miss performs one source read.

Hot product

30% of traffic; one recomputation takes 200 ms. Treat its expiry arrivals as a separate burst calculation.

Source capacity

1,200 source reads/second at the latency target in this fictional exercise. Leave headroom; do not assume spare capacity beyond this limit.

Request deadline

500 ms end to end, including 100 ms reserved for returning a response. All queueing, refresh waiting, and retries share the remaining budget; they do not receive new independent deadlines.

Freshness

Only public descriptions are cached. A response may be at most 30 seconds old, measured from its authoritative source observation. A retained copy is already 20 seconds old when refresh starts. Prices charged and permissions are checked elsewhere.

Failures

The refresh owner can time out or pause. The shared cache can also be unavailable. Client waiting and retries must be bounded.

Produce: Three calculations, an expiry timeline, a freshness policy, and a source-protection plan. The worksheet is the artifact you will review.

Useful preparation

• Caching & performance →