Cache Design
Stores hot data in fast memory to cut latency and database load — with explicit invalidation and eviction policies.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Cache Design is non-negotiable.
① What it is (30 seconds)
Stores hot data in fast memory to cut latency and database load — with explicit invalidation and eviction policies.
② How it works in system design
Cache-aside: app reads cache, on miss reads DB and populates. Writes update DB then delete cache key. TTL + LRU eviction. Watch hot keys and stampede (singleflight).
Typical placement
Client→Edge / Gateway→Cache→Services→Data stores
③ Concrete system design example
Scenario: News feed: precomputed feed cells cached in Redis per user_id with 60s TTL. On new post, fan-out worker deletes affected users’ cache keys.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Cache-aside vs read-through? | Cache-aside: app owns logic. Read-through: cache library fetches DB on miss — simpler app code. |
| How prevent stale reads? | TTL safety net + delete-on-write + version keys for critical entities. |
| Thundering herd? | Singleflight: one thread repopulates; others wait on same key. |
⑤ Seen in these system designs
- URL Shortener — redirect path
- Distributed Cache — full design
- News Feed — feed cells
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Pattern named
- TTL + eviction
- Invalidation on write
- Hot key plan
- Stampede mitigation