Day 7 Review — Content Delivery Networks (CDN) Deep Dive — 2026-08-01

Score: 8.7 / 9 (96.7%) — 🎉 NEW PERSONAL BEST (again) Verdict: Two back-to-back 96%+ days. Two more spaced-rep gaps closed simultaneously (JWT + push-directionality). The only remaining chronic gap is capacity math in architecture answers.

Question-by-question

Q1 (MCQ) — s-maxage vs max-age vs stale-while-revalidate ✅ 1.0 / 1.0

B — Correct. You correctly separated shared-cache (CDN, controlled by s-maxage) from browser cache (max-age) and understood that SWR applies to both. This is the header combo that trips up most engineers.

Q2 (MCQ) — Low CDN hit rate root cause ✅ 1.0 / 1.0

B (query-param cache-key pollution) — Correct. The single most common real-world cause. You'd recognize this in an audit.

Q3 (MCQ) — Anycast vs DNS routing ✅ 1.0 / 1.0

B — Correct. Anycast + BGP is the modern default (Cloudflare, Fastly). No DNS trick needed.

Q4 (T/F) — JWT instant revocation ✅ 1.0 / 1.0 · 🎯 GAP CLOSED

False — Correct.

This is significant. JWT vs sessions has been flagged Medium since Day 1 (you conflated the two trade-offs) and again on Day 4 (only partial credit). Today you nailed the directionality of the trade-off: statelessness is a JWT strength, but instant revocation is a session-cookie strength. That precision is exactly what interviewers listen for.

Moving JWT vs sessions to "Low, maintenance-only" in the queue.

Q5 (T/F) — no-cache prevents storage ✅ 1.0 / 1.0

False — Correct. no-cache = "may store, must revalidate"; no-store = "must not store." Trap avoided.

Q6 (Short) — Push mechanism directionality × 5 ✅ 1.0 / 1.0 · 🎯 GAP CLOSED

Perfect 5/5, and — critically — you got the trading UI (Q6.1) correct this time.

Look at this trajectory: - Day 3 Q6.1 (original): trading UI → you picked SSE → wrong (SSE is one-way; orders need bidirectional). - Day 7 Q6.1: trading UI → you picked WebSocket → correct.

That's the exact instinct — "wait, do orders need to go back to the server too? then not SSE" — locked in. Removing "bi-directional check for push mechanism" from the queue.

All 5 mappings were textbook: | Scenario | Your answer | Why correct | |---|---|---| | Stock trading (bidirectional) | WebSocket | ✅ Duplex needed for orders | | CI/CD log stream | SSE | ✅ One-way server→client, HTTP-native | | Mobile chat, app in background | Push (APNs/FCM) | ✅ OS-level delivery, no WebSocket possible | | Public outage page broadcast | SSE | ✅ Broadcast one-way, browser-friendly | | Microservice 10k-row stream | gRPC-streaming | ✅ HTTP/2 native, best for internal RPC |

Q7 (Short) — Origin Shield explanation + alternative ✅ 0.95 / 1.0

Excellent structured answer: - ✅ Definition: "intermediate caching layer... centralized gatekeeper to absorb traffic and collapse duplicate cache-miss requests" - ✅ Failure mode explicitly named: "thundering herd (or cache stampede)" - ✅ Alternative: request coalescing at single-server layer with clear mechanics — "server processes only one request and makes the remaining threads wait for or share that exact same result"

The only reason it's not 1.0: you could name the specific vocabulary — single-flight (Go's singleflight package, popularized by Groupcache, is the archetypal implementation). Small vocabulary polish, but the concept is completely correct.

Q8 (Scenario) — E-commerce CDN design ✅ 0.8 / 1.0

All 5 sub-parts covered with sharp structure:

• ✅ Cache-key: path + country/currency + device type; strip UTM, tracking cookies, headers. This is actually better than my rubric — you correctly identified that pricing/currency needs to be a key axis for a global catalog. Nice.
• ✅ Cache-Control: public, max-age=10, stale-while-revalidate=50. Valid: 10s fresh + 50s SWR = 60s total staleness ceiling, matches SLA.
• ✅ Invalidation: tag-based purging via webhooks — perfect.
• ✅ Origin protection: shield + request coalescing + rate limiting — correct.
• ✅ Personalization: cache shell + hydrate via AJAX/ESI — textbook.

Two sharpen-ups:

1. Use s-maxage in your Cache-Control recipe. Your version caches the same duration in browser and CDN, but that's wasteful — the CDN can hold much longer than the browser. The idiomatic recipe: Cache-Control: public, s-maxage=60, max-age=0, stale-while-revalidate=300, stale-if-error=86400 s-maxage → CDN holds 60s. max-age=0 → browsers don't hold at all (always revalidate). stale-if-error=86400 → keep serving stale for a day if origin dies. This is the recipe you should be reflexively writing.

2. ⚠️ CAPACITY MATH — third quiz in a row missing it (Day 3 Q8, Day 6 Q8, now Day 7 Q8). This is now your only consistent gap. Interviewers WILL press for numbers on any architecture answer. The math for this one takes 15 seconds:

500M req/day ÷ 86400 ≈ 5.8k QPS avg, peak ~5× = 30k QPS. At 98% hit rate, origin sees ~600 QPS — trivially handled by even a small origin fleet. Storage: 20M SKUs × ~50KB avg HTML = 1 TB distributed across CDN PoPs, negligible per PoP.

Bake this reflex in: when the problem statement has a number in it, your answer must have a number in it. Always.

Q9 (Design) — CDN post-mortem: 92% hit rate + 15× origin spike ✅ 0.95 / 1.0

Excellent. You correctly diagnosed: - ✅ Root cause: request hit rate ≠ byte hit rate — 8% of requests being large objects (videos, images) can dominate bandwidth - ✅ Recognized the "8% of a much larger traffic base" volume compounding effect - ✅ Named the divergence explicitly: "Request hit rate and byte hit rate can diverge dramatically."

Metrics not watched (both correct): - ✅ Origin fetch rate (per-second origin request count) - ✅ Byte hit ratio (origin byte offload)

Three fixes: - ✅ Alerts on origin bandwidth + fetch rate + byte hit ratio - ✅ Longer TTLs + origin shield + pre-warming (combined into one bullet — fine) - ✅ Fix cache fragmentation (query strings, Vary, cookies on static) — this was NOT in my rubric but is a real production fix that would show senior maturity in an interview. Nice add.

Only small nit: didn't explicitly name the pattern — this is the "cold cache stampede after content refresh" failure mode, same underlying failure as Day 5 Q9 applied at CDN scale. Naming the pattern signals you've seen it before.

Score progression

Running average: ~83% (climbing). Two back-to-back 96%+ days on unrelated topics (caching internals + user-facing CDN infrastructure). This is not a one-day fluke.

What today proves

1. Spaced repetition just closed TWO MORE gaps in a single session (JWT, push-directionality). Total resolved in the last 2 quizzes: four gaps — bandwidth vs latency, tail-amp, JWT vs sessions, push-mechanism directionality. That's your entire "recurrent misses" list, cleared.

2. Your senior post-mortem structure is now consistent. Days 3, 5, 6, and 7 all showed the same disciplined pattern (name → root-cause → 3 fixes with trade-offs → bonus insight). Interviewers give bonus signal for structured answers.

3. Your vocabulary is FAANG-level. In Q7 you said "collapse duplicate cache-miss requests" and "consolidating concurrent inbound requests into a single upstream fetch." That's how senior engineers describe request coalescing. Contrast with Day 1 where you said "DNS is a type of library." You've come miles.

Weak-area queue — dramatic cleanup

Escalating capacity-math from "Low, ongoing" to HIGH because it's now the only thing between you and consistently-perfect architecture answers. This is exactly the situation where a targeted drill worked for tail-amp on Day 5. Same play.

Habit to burn in

Every time you write an architecture answer, before writing anything else, calculate: QPS avg, QPS peak, storage, bandwidth. Write those four numbers at the top. Even wrong numbers are better than no numbers. Even ballpark numbers are worth 20% of the answer's credit in an interview.