Brief #02 · Backend
Redis Cache for a Slow API
Easy⏱ 6-10 hSoon
Put a cache in front of a two-second endpoint and get it under 50 ms, without ever showing stale prices.
Outlines are free · building with tracking needs Pro
RThe briefFrom the team
The product page calls an inventory service that takes about two seconds to answer, and it's the slowest thing on the site. Product managers keep asking why the page feels sluggish. Speed it up, but the price on the page must never be more than 30 seconds out of date.
What you'll build
- 1A deliberately slow upstream service (sleep 2s) and an API in front of it.
- 2Cache-aside with Redis and a TTL; measure p50 and p95 before and after.
- 3Invalidate the key when a price changes, so updates show up immediately.
- 4Reproduce a cache stampede (500 requests on an expired key) and fix it with a lock or request coalescing.
- 5Decide what to serve when Redis is down, and test it.
Step-by-step walkthrough
Walkthrough coming soon
This project's step-by-step walkthrough, with real outputs at every step, is still being written. You can read the brief and try it on your own meanwhile; tracking opens when the walkthrough is ready.
Done when
- Cached p95 is under 50 ms in your benchmark.
- During a stampede the upstream sees one request, not hundreds.
- With Redis stopped, the API still answers (slowly) instead of erroring.
- A short write-up explains your TTL choice.
Stretch goals
- Stale-while-revalidate: serve the old value while refreshing in the background.
- Add HTTP caching headers (ETag, Cache-Control) so browsers help too.