quest

Sign in to start training

quest keeps your progress, streaks, and scores tied to your account — so you can pick up on any device.

Synced everywhere. Progress follows you across laptop and phone.
Streaks & stats. See your daily run and every score over time.
Your profile. A name and avatar for the work you do here.

We only use Google to sign you in and sync progress. No posting, no contacts — ever.

← All subjects · System Design

System Design Intermediate

02  Caching

The fastest query is the one you never run. A cache buys you latency and shields the database -- and it charges you back in staleness, invalidation bugs, and brand-new failure modes.

Step 1 / 2

A product page runs 12 database queries and takes 800 ms; the site does 100 reads for every write, and product data changes only when a merchant edits it. Add caching: say what you cache, where the cache lives, the TTL you pick, and exactly what happens when a merchant updates a price.

Hints
  • What exactly do you cache: each of the 12 query results separately, or something coarser? One of these is far simpler to keep correct.
  • Where does it live: the browser, the CDN, an application cache, or the database itself? Different content belongs in different layers. And what is the cache key?
  • Waiting for the TTL to expire is not an invalidation strategy. What can the write path do the moment the merchant saves?
Your design is reviewed against a hidden rubric.