System Design Caching Interview Talk Track
System design caching interview talk tracks separate “we’ll add Redis” from a design that explains where, what, how long, and what breaks. This guide gives you a structured script for API, application, and CDN caches without hand-waving consistency away.
Start with the job of the cache
A cache exists to trade freshness for latency, cost, or load. Say the tradeoff before product names.
Talk track:
“Reads dominate and the working set fits memory; I’ll cache popular keys to cut DB QPS, accepting a short inconsistency window on updates.”
If writes dominate or every read must be strongly fresh, caching may be the wrong first lever—or must sit behind careful invalidation.
Where caches live (pick deliberately)
| Layer | Good for | Watch-outs |
|---|---|---|
| Client / browser | Static assets, user-specific display data with care | Privacy, stale UX, hard purge |
| CDN / edge | Public media, static pages, geo latency | Invalidation delay, cache keys |
| API gateway / reverse proxy | Identical GETs, auth-aware carefully | Authorization leaks |
| App-local (in-process) | Ultra-hot keys per instance | Coherence across instances |
| Distributed (Redis/Memcached) | Shared hot keys, sessions, rate counters | Hot keys, memory, failover |
| DB buffer pool | Always there—mention, do not redesign it | Not a substitute for app cache |
Do not stack five caches in the first drawing. Add the one that hits the bottleneck from your capacity estimate.
The four questions to answer every time
- Key: what is the cache key? (include tenant/user if needed)
- Value: object blob vs IDs vs rendered fragment
- TTL: time-based expiry—what is acceptable staleness?
- Invalidation: on write, delete/update which keys?
Missing invalidation is the classic junior tell.
Read patterns worth naming
- Cache-aside (lazy): app reads cache; on miss, load DB, populate cache
- Read-through: cache library loads on miss
- Write-through: write cache and DB together
- Write-behind: acknowledge write after cache; flush DB async (higher risk—say it)
Default interview choice: cache-aside for reads + explicit delete on write for that key (and secondary indexes if any).
Talk track:
“Cache-aside with TTL plus delete-on-write for the primary key; list endpoints get short TTL because invalidation is wider.”
Eviction and memory
- LRU / LFU / TTL eviction—name which you assume
- Size the cache from working set, not from total dataset
- Hot-key risk: one key owns too much QPS → local + distributed, or request coalescing
Thundering herd / stampede
When TTL expires on a hot key, many servers miss together.
Mitigations to mention:
- Soft TTL / early refresh by one winner
- Singleflight / request coalescing
- Probabilistic early expiration
- Stale-while-revalidate at CDN
Talk track:
“On expiry of a hot key I’d coalesce misses so only one load hits the DB.”
Consistency scripts (keep honest)
| Need | Approach |
|---|---|
| Mostly fresh enough | Short TTL + delete on write |
| Read-your-writes for actor | Bypass cache on user read path or version tokens |
| Strong read-after-write global | Caching may be wrong or needs versions / synchronous update |
| Multi-object invariants | Avoid caching partial aggregates without care |
Never claim “Redis is always consistent with Postgres” without a mechanism.
CDN-specific lines
- Cache public GETs by URL + vary headers carefully
- Authenticated HTML often bypasses CDN or uses signed URLs for media
- Purge on publish for editorial content; TTL for profiles
First five minutes
- Confirm read/write ratio and freshness needs
- Point to the bottleneck component
- Choose one primary cache layer
- Define key/TTL/invalidation
- Mention stampede and failure mode (cache down → DB protection)
Failure mode you must not skip
If the cache dies, does the DB melt? Mention load shedding, degraded mode, or reserved DB capacity. Caches are not magic availability; they can amplify outages when they fail.
Freeze recovery
- Erase extra cache boxes
- Write: key / TTL / invalidate-on-write
- Tie back to QPS estimate (“cuts read QPS by ~hit rate”)
- Add stampede line only after the basic path is clear
Soft practice note
Caching interviews are narration-heavy: tradeoffs, keys, and failure modes. If you want a Chrome side panel to practice this system design caching talk track under timed pressure, Luna Interview is built for calm rehearsal. Use it to build structured communication—not to fake production scars or to violate interview rules.
Day-of checklist
- [ ] Bottleneck named before Redis appears
- [ ] Layer chosen (CDN vs app vs distributed)
- [ ] Key + TTL + invalidation spoken
- [ ] Hit-rate assumption rough but conscious
- [ ] Stampede mentioned for hot keys
- [ ] Cache-down behavior considered
Justify the cache—then draw it once, clearly.
Rehearse with an AI interview copilot, then browse commonly reported interview questions.