Caching
Caching capstone: multiple-choice review
Crux Multiple-choice synthesis across the caching track — layer ownership, TTL cascade, stampede vs dogpile protection, validators, SWR, and invalidation propagation as one composed strategy.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole track. None tests a single directive in isolation — each asks you to reason about how two or more layers compose, which is where real caching bugs live.
Goal
Confirm you can wire layer ownership, TTL cascade, stampede protection, validators, and stale-while-revalidate into one coherent strategy — the synthesis the individual units built toward.
Quiz
Completed
A request passes through CDN, reverse proxy, Redis, and the DB. An editor changes a product, the write path updates the DB and deletes the Redis key, but users still see the old price for an hour. Where is the bug?
Heads-up A deleted Redis key forces a miss that recomputes from the DB — the fresh value. A user pinned to the old price for an hour points at an outer cache (the CDN) holding a copy nobody invalidated, not at Redis.
Heads-up A DB query/buffer cache is invalidated automatically by the write that changed the row. The stale copy survives in a layer with no link to the write path — the CDN.
Heads-up Mismatched TTLs do not error; they silently serve stale. The longer outer TTL wins for the user until it expires or is explicitly purged.
Quiz
Completed
You set the CDN to s-maxage=3600 but the app revalidates its Redis fragment every 60s. Why is this a composition bug regardless of which numbers are correct individually?
Heads-up Redis is not the source of truth, and even if it were, an inner refresh is invisible to an outer cache. The CDN serves its own copy for the full 3600s irrespective of Redis.
Heads-up s-maxage is precisely the directive shared caches like the CDN obey; max-age targets the private browser cache. The CDN honours the 3600s.
Heads-up Shrinking both equally keeps the outer window larger-or-equal than the inner, so the same stale-serving gap remains. The defect is ordering (outer must be ≤ inner), not the absolute size.
Quiz
Completed
A hot key with thousands of concurrent readers expires. You can add (a) a per-key mutex so one request recomputes while the rest wait, or (b) stale-while-revalidate. A senior usually reaches for SWR first. Why?
Heads-up A scoped per-key lock with a timeout does not deadlock; single-flight is a sound stampede defence. The reason to prefer SWR is latency, not safety — the mutex makes waiters block, SWR does not.
Heads-up The opposite: SWR's whole mechanism is serving a stale copy while it revalidates. You choose it when bounded staleness is acceptable; a mutex is right when readers must see the recomputed value.
Heads-up A mutex (single-flight) is exactly an origin-protection mechanism — it collapses N misses into one recompute. Both protect origin; they differ in whether waiters block.
Quiz
Completed
A public API read costs 40ms to compute and changes rarely. You want low latency, low origin load, and bandwidth savings on the wire. Which combination composes these correctly?
Heads-up max-age alone gives no graceful expiry (no SWR, so the first reader after expiry eats the 40ms) and no cheap revalidation (no ETag, so every revalidation ships the full body). It solves one cost and ignores two.
Heads-up no-store forbids the edge and browser from caching, throwing away the cheapest wins (zero-RTT browser hits, edge offload, 304s). Server-side caching alone leaves every client paying full RTT and bandwidth.
Heads-up An ETag still requires a round-trip per request to get the 304; without s-maxage there is no local hit, and without SWR the revalidation is synchronous. ETag saves bandwidth, not the round-trip or the latency cliff.
Quiz
Completed
A logged-in dashboard renders per-user billing data and sits behind a shared CDN. The handler returns 200 with no Cache-Control. What is the actual risk, and the correct fix?
Heads-up That direct-to-client assumption is exactly what an edge config change, proxy, or surrogate-key rule can silently revoke. This is the Steam 2015 leak class: an un-annotated authenticated 200 stored and cross-served.
Heads-up Vary: Cookie keys on the whole cookie, collapsing hit rate to near zero and risking collisions on one missed normalization. For per-user data the answer is private/no-store, not a fragile Vary.
Heads-up A short TTL does not make per-user content safe at a shared cache — for the whole window the CDN serves one user's billing page to others. TTL controls staleness, not audience.
Quiz
Completed
Across the stack, which statement about failing open during an origin outage is correct?
Heads-up SWR triggers on expiry and revalidates against a healthy origin; if origin is down, the background revalidation fails. stale-if-error is the directive that specifically covers the error and unreachable case.
Heads-up Some data is unsafe stale — a stock-availability flag served stale can oversell. The senior call is per-resource: long for a price list, short or zero for correctness-critical state.
Heads-up Any caching layer can fail open — a reverse proxy with stale-if-error, an application cache configured to return its last value on origin error. It is a composition property of the whole stack.
Recap
The track’s through-line is one composed strategy: assign each layer the data it owns, shrink freshness windows outward (or purge the outer layer on every inner change), protect the origin on a hot-key expiry with single-flight or SWR, save bandwidth with ETag-driven 304s, scope per-user responses with private/no-store, wire invalidation into the write path so it propagates Redis → proxy → CDN in order, and fail open with stale-if-error tuned per resource. No single directive is the answer; the answer is how the layers compose.