Designing a multi-level cache hierarchy on purpose

Browser cache, CDN edge, application cache (Redis/Memcached), database — each layer catches what the layer before it missed, and each is progressively more expensive to hit. The previous lessons in this domain went deep on the application-cache layer specifically (eviction, stampedes, clustering); this lesson is about how the layers relate to each other, not any one layer in isolation.

Setting a 60-second TTL at the browser, the CDN, and the application cache layer sounds consistent, but it means all three layers go stale and need refreshing at roughly the same moment — defeating some of the purpose of having multiple layers at all, since the whole stack effectively behaves like one layer with extra hops. The layers should have deliberately different TTLs, chosen for what each layer is actually good at absorbing.

The general principle: TTL should shrink (or shift toward active invalidation) the closer a layer sits to the actual source of truth, and can safely grow the further out (and more per-user) a layer is.

Adding a layer that serves the exact same TTL-governed content as the layer right next to it, with no meaningfully different audience or access pattern, adds operational complexity (one more cache to invalidate correctly, one more place staleness bugs can hide) without adding real benefit. A small internal admin tool with a handful of daily users gains little from a CDN layer in front of an already-fast application cache — the CDN's real value (protecting against thousands of simultaneous requests, serving geographically distant users fast) doesn't apply at that traffic scale.

A support ticket saying "I see old data" requires checking each layer in turn — did the browser cache it too long, does the CDN have an old copy, is the application cache stale, or is the database itself not actually updated yet — because the fix is completely different depending on which layer is actually responsible. Designing each layer's TTL and invalidation strategy deliberately (as opposed to "caching felt like a good idea, so we added one everywhere") is what makes that triage tractable instead of a guessing exercise across four unrelated systems.