Day 6 Review — Cache Strategies Deep Dive — 2026-08-01

Score: 8.65 / 9 (96%) — 🎉 NEW PERSONAL BEST Verdict: Breakthrough day. Two chronic weak areas (bandwidth vs latency, tail-amp application) resolved simultaneously — AND after a 6-day gap since your last quiz. That last part matters more than the score: material that survives a 6-day pause is genuinely internalized, not short-term memorized.

Question-by-question

Q1 (MCQ) — Cache invalidation at fleet scale ✅ 1.0 / 1.0

B (CDC + Kafka + consumers) — Correct. Recognized that at 200 microservices / 40 writers, per-writer invalidation logic is unworkable.

Q2 (MCQ) — L1 in-process cache biggest risk ✅ 1.0 / 1.0

B (cross-instance invalidation is hard) — Correct. This is the trade-off that decides whether L1 is worth adding.

Q3 (MCQ) — Global product catalog architecture ✅ 1.0 / 1.0

C (per-region cache + CDC invalidation) — Correct. The FAANG-scale default for read-heavy multi-region workloads with tolerable staleness.

Q4 (T/F) — Bandwidth halves latency? — ✅ 1.0 / 1.0 · 🎯 GAP CLOSED

False — Correct.

This is a milestone. Look at the trajectory: - Day 2 Q4 — you answered False correctly (fresh from the lesson) - Day 4 Q5 — you regressed and answered True (concept hadn't consolidated) - Day 6 Q4 — you answered False again, correctly, after a 6-day gap

That's spaced repetition doing exactly what it's supposed to do. This concept is now genuinely locked. Removing from the High-severity revisit queue.

Q5 (T/F) — Tail-amp with N=30, P99=50ms ✅ 1.0 / 1.0 · 🎯 MAINTAINED

True (~26%) — Correct. 1 − 0.99^30 = 0.26.

Small ask: for future tail-amp questions, show the arithmetic in your answer (1 - 0.99^30 = 0.26). Two reasons: 1. Guards against accidental pattern-matching (you're forced to compute). 2. Shows the habit to an interviewer — the moment you write the formula on the whiteboard, they know you can reason at scale.

Q6 (Short) — 3 refresh pattern mappings ✅ 1.0 / 1.0

All 3 nailed: 1. News homepage CDN, 2s staleness OK → stale-while-revalidate ✅ 2. 50 feature flags, 30s freshness → scheduled background refresh ✅ 3. 1000 hot profiles, dozens of accesses/min → refresh-ahead ✅

Your matching-pattern-to-scenario skill is now consistently 100% (Day 4 Q6 = 5/5, Day 5 Q6 = 4/4, Day 6 Q6 = 3/3). This is reliable fluency.

Q7 (Short) — CDC explanation + 2 tools ✅ 0.9 / 1.0

Solid answer: - ✅ Correctly defined CDC as row-level change tracking - ✅ Correctly identified the killer feature: reads native transaction logs asynchronously with zero source-DB overhead - ✅ Debezium + Kafka Connect — great pairing (Debezium is built on Kafka Connect for many deployments)

Small addition for FAANG-perfect answer: the 4 reasons CDC scales — decouples writers from downstreams, guarantees atomic capture of every change, replayable (rewind Kafka on consumer bug), multi-target (same event → cache + search + analytics + ...).

Q8 (Scenario) — 500M-user profile cache design ✅ 0.8 / 1.0

All 4 sub-parts covered with structure: - ✅ L1 + L2 tiering with clear rationale - ✅ Write-through justified by SLA (valid alternative to cache-aside for a 5s SLA) - ✅ CDC + pub/sub L1 invalidation - ✅ Hot user (Taylor Swift) mitigations mentioned

Two things to sharpen:

1. The "1-second TTL on L1 for hot users" idea actually makes it worse. Shorter TTL means more L1 misses → more L2 traffic for that hot key → your L2 shard hosting Taylor Swift's profile now takes more load, not less. Better approaches: - Longer L1 TTL for hot keys (accept slightly more staleness for hugely more L1 hits) — reverse of what you said - Replicate the hot key across N L2 shards, client picks randomly (distributes L2 load) - Combined: long L1 TTL + hot-key replication in L2

2. No capacity math. For a 500M-user, 100k QPS design, an interviewer expects numbers: "500M profiles × ~5KB avg = 2.5 TB raw, but working set is ~5% = 125 GB, fits in ~2-3 Redis nodes with headroom." That's the discipline from Day 2's Little's Law / back-of-envelope. Always include it in architecture answers.

Otherwise: solid structured design that uses real terms (write-through, TTL, pub/sub, CDN offload).

Q9 (Design) — L1 stale-data post-mortem ✅ 0.95 / 1.0

Excellent. Diagnosed cleanly: - ✅ L1 caches on each app process aren't being invalidated - ✅ Correctly noted the 60s = L1 TTL ceiling matches the observed stale window

Fixes: all 3 match the rubric perfectly: - ✅ Shorten L1 TTL (with the honest note about DB/Redis load increase) - ✅ Pub/sub invalidation across app instances - ✅ Version tracking (append version to L1 entries)

Only small nit: "L1 can reject outdated local entries" — for version-tracking to work, L1 needs to know the current version, which typically requires a cheap L2 lookup for user:X:v on every read. That's still fast (~1ms) but it's a network hop. Worth being explicit about the cost.

This is genuinely a senior-level post-mortem answer. The structure (problem statement → root cause → 3 fixes with trade-offs) is exactly what an incident review at a senior interview needs.

Score progression

Running average: ~82%. Days 3 and 6 both hit 90%+. Day 4 looks more and more like an outlier — everything since is on an upward track.

What today proves

1. Spaced repetition is working exactly as designed. Both High-severity weak areas (bandwidth vs latency, tail-amp) resolved within 3-4 encounters each. That's the loop paying off.

2. The material sticks across breaks. A 6-day gap between Day 5 and Day 6, and you still hit 96%. This is the durable kind of learning that survives interview season. Cramming produces short-term memory; spaced practice produces long-term skill.

3. Your post-mortem structure is now senior-level. Day 3 Q9 (WebSocket incident), Day 5 Q9 (cold cache), Day 6 Q9 (L1 stale) — all showed the same clean pattern: name the problem → root-cause it → 3 fixes with trade-offs. Interviewers pattern-match on this.

Weak-area queue — significant cleanup today

Two chronic High-severity items → resolved. That's real progress.

One habit to reinforce

Show your arithmetic in T/F questions with numbers. You've earned the skill; now show it. On Q5 the answer was right but you didn't write 1 − 0.99^30 = 0.26. In an interview, showing the math is worth more than the answer alone — it proves you thought, not guessed.