Caching
Cache layers: multiple-choice review
Crux Multiple-choice synthesis across the cache-layers unit — the latency ladder, where to cache, hit-ratio break-even, and the wrong-layer and double-caching failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make in a real system — not a definition to recite, but a tradeoff to weigh the moment someone says “just add a cache.”
Goal
Confirm you can connect the latency ladder, where to put a cache, the hit-ratio break-even, and the wrong-layer and double-caching failure modes — the synthesis the lesson built toward.
Quiz
Completed
A team fronts a Postgres primary-key lookup (warm, served from the buffer pool in ~0.3 ms) with an in-region Redis cache (~1 ms round trip). p99 read latency rises. Why?
Heads-up Redis is fast and effectively non-blocking for simple GETs; throughput is not the issue. Latency rose because the network round trip to Redis is slower than the warm buffer-pool read it fronts.
Heads-up Redis runs as a separate process / instance and does not shrink Postgres's buffer pool. The regression is the added network hop on a path that was already a RAM hit.
Heads-up Key hashing is nanoseconds — irrelevant next to the ~1 ms network round trip. The structural mistake is fronting a RAM-speed origin with a network-speed cache.
Quiz
Completed
A read endpoint runs a 3-table join taking 80 ms, called 50×/sec, on data that changes a few times a day. Where does the cache belong?
Heads-up Lower layers help I/O-bound reads, but the 80 ms is CPU work — joining and aggregating, not disk reads. The page cache makes the rows fast to fetch; it cannot skip recomputing the join. You must cache the computed result.
Heads-up Wrong layer for a data endpoint. The CDN is keyed by URL and is for static or near-static responses; a long edge TTL means a data change takes until expiry to appear globally, and personalized variants leak across users.
Heads-up 50 calls/sec of 80 ms work is real origin load and real tail latency, and the data tolerates staleness. This is a clean cache fit; skipping it trades a cheap, well-understood win for needless origin pressure.
Quiz
Completed
A cache with a 35% hit ratio fronts an 80 ms origin behind a 1 ms lookup. Average latency is 0.35×1 + 0.65×(1+80) ≈ 53 ms — better than 80. So why is a 35% hit ratio still a red flag?
Heads-up The average improves only because the origin is slow enough to absorb the miss tax, but 35% reuse is poor: misses still pay cache+origin, and you have bought a new moving part and invalidation path for a thin win that is fragile to traffic changes.
Heads-up Hit ratio is precisely the number that justifies a cache. Below a break-even ratio the miss tax (cache lookup plus full origin) makes the cache strictly worse than no cache.
Heads-up A low hit ratio is a workload / key-design signal — one-hit-wonder keys, too-short TTL, poor key cardinality — not a stability bug. It tells you the cache may not be worth its cost here.
Quiz
Completed
Why is the OS page cache the most underrated layer when deciding whether to add Redis?
Heads-up The page cache stores raw file pages, not compressed data, and that is not the point. Its value is that hot reads are served from RAM with zero work from you, so the origin may already be RAM-speed.
Heads-up The page cache is per-machine and local — it cannot be shared across instances, which is exactly what an application cache adds. Its relevance here is that it makes a single node's hot reads RAM-fast.
Heads-up The page cache is about read latency, not freshness, and is kept coherent through the filesystem. The reason it matters here is that it makes the origin fast, so a network cache in front may add latency instead of removing it.
Quiz
Completed
A value is cached in Redis (invalidated on write) AND its rendered response is cached at the CDN with a 5-minute TTL. After a write, users still see old data for minutes. What is the failure and the structural fix?
Heads-up Redis is fresh — it was invalidated correctly. The stale copy is at the CDN. Lowering the Redis TTL changes nothing because the CDN layer is the one lying; the problem is two uncoordinated layers, not one TTL.
Heads-up Shortening the edge TTL only shrinks the staleness window — the layers are still uncoordinated and a write is still invisible until expiry. The real fix is purge-on-write or a single owning layer, not a smaller window.
Heads-up Stale-on-stale here is caused by two independent layers caching the same fact, which is avoidable: give each fact one owner and one invalidation path. A single, correctly-purged cache layer does not drift against itself.
Quiz
Completed
An engineer caches a per-user 'recommended for you' fragment at the CDN to cut origin load. Some users start seeing other users' recommendations. Root cause?
Heads-up The model is fine — the fragments are served from a shared CDN entry keyed by URL, so user A's cached fragment is returned to user B. It is a caching-layer mistake, not a model bug.
Heads-up Even if the origin reads the cookie correctly, a URL-keyed CDN hit never reaches the origin — it serves whatever it cached first. The defect is caching identity-dependent data at a layer that cannot tell users apart.
Heads-up This is a cross-user leak, not staleness. A shorter TTL still serves one user's fragment to another within the window. Personalized data simply must not be cached at a shared URL-keyed layer.
Recap
The through-line: caching is a latency ladder — L1, RAM, page cache, Redis, CDN — and a cache only helps when it fronts a genuinely slower origin, the hit ratio is high, and the data tolerates staleness. The page cache and DB buffer pool often make the origin RAM-fast already, so check real origin latency before reaching for Redis. The senior failures all repeat: fronting a fast origin, justifying a cache on a weak hit ratio, caching personalized data at a URL-keyed CDN, and double-caching one fact at two layers with independent TTLs. Cache as close to the consumer as the data’s volatility allows; give every fact one owner and one invalidation path.