Multi-Layer Caching: CDN vs App-Layer vs DB-Layer Lab (Interactive)
Toggle browser, CDN, gateway, Redis, and buffer-pool tiers and cascade live QPS down to physical disk I/O. Build a defense-in-depth caching stack layer by layer and watch surviving traffic multiply-shrink toward the NVMe tier.
5-Layer Defense-in-Depth Cache Stack
Browser → CDN → Gateway → Redis → Buffer Pool → Disk. Cascade real traffic and see what survives to NVMe.
How It Works Under the Hood
High-scale services never trust one cache; they stack five filters: the browser cache (0ms, fingerprinted assets), edge CDN PoPs (5–20ms, public HTML/media), API-gateway micro-cache (1–3ms, 5–60s authenticated spikes), application Redis (0.5–1.5ms, entities and sessions), and the database buffer pool (0.1–0.5ms, raw 8/16KB pages in InnoDB/Postgres RAM). Because survivors multiply — 50% absorbed here, 80% of the rest there — a tiny fraction reaches disk, letting Reddit and YouTube run global traffic on lean database footprints while the buffer pool quietly saves SSD I/O on every Redis miss.
Core Architectural Principles
- Surviving traffic = QPS × Π(1 − hitᵢ): mediocre per-layer ratios compound into near-total disk protection.
- Each layer has a distinct job: edge for static/public, gateway for burst micro-caching, Redis for entities, buffer pool for pages.
- Staleness debugging across five layers requires unified headers, CDC-driven invalidation, and distributed trace IDs.
In full-stack designs, walk the request Browser → CDN → Gateway → Redis → Buffer Pool → Disk with per-layer hit assumptions and latency numbers — interviewers score this as systems depth. Explicitly name the database buffer pool: showing you know Postgres itself caches pages in RAM separates seniors from memorizers. Cite Reddit’s Fastly + Redis/Cassandra stack as the reference architecture.
Compounding layers deliver huge throughput on minimal hardware but make staleness debugging and coordinated invalidation a cross-five-tier problem.