You're designing a multi-tier caching architecture for a global e-commerce site: CDN edge nodes, a reverse-proxy cache (e.g., Varnish or Nginx), an application-level cache (e.g., Redis), and the database's own buffer pool. What does each tier optimize for, and how do you reason about propagating an invalidation across all four when a product price changes?

## Four genuinely different bottlenecks A multi-tier caching architecture exists because no single cache location can simultaneously minimize network latency to a globally distributed user base, protect application compute from repeated rendering work, avoid redundant expensive data lookups, and avoid disk I/O inside the database — these are four genuinely different bottlenecks, and each tier is purpose-built to attack one of them. ## What each tier optimizes for - **The CDN's job is minimizing physical network latency** and shielding the origin infrastructure from the full weight of global traffic. Edge nodes are placed in many geographic points of presence, so a user in São Paulo gets a response from a nearby edge server instead of round-tripping to wherever the origin data center actually is; at scale, this also means the origin only ever sees cache-miss traffic, which is a small fraction of total requests for popular content. - **The reverse-proxy cache's job is protecting application compute**: it sits immediately in front of the app servers (usually within the same data center or region) and caches full rendered HTTP responses keyed by URL, so an identical request for the same page doesn't have to re-run application logic, template rendering, or authorization checks — this matters even for traffic the CDN didn't catch, e.g. because the CDN's TTL was very short or the response varied per-region. - **The application-level cache's job is avoiding redundant expensive computation** or data assembly inside the app tier itself — not full HTTP responses, but arbitrary derived data: a product's price and inventory count fetched from `Redis` instead of re-querying and re-joining several database tables on every single request, even for requests whose rendered HTML differs (e.g., a personalized page that embeds the same product price). - **Finally, the database's buffer pool job is minimizing disk I/O** for whatever query volume does reach the database after all the layers above have already absorbed most of the traffic — it keeps hot pages/rows resident in RAM so even a 'full miss' through every application-level cache is still relatively cheap. ## Blast radius grows outward, reliability drops Because each tier catches a successively smaller, more filtered slice of traffic, the tiers closer to the user have both the largest blast radius (many more cached copies, spread across the globe) and the least reliable, slowest invalidation propagation, while the tiers closer to the database have the smallest blast radius and the fastest, most reliable invalidation. This asymmetry is the central fact to reason about when propagating a price change: the database write is instantaneous and authoritative by definition (it is the change), but reflecting that change everywhere a stale copy might exist gets progressively harder and slower moving outward. - **Redis** is typically a single logical store (or small cluster) reachable with one delete/update call and near-instant propagation. - **The reverse-proxy layer** may have several nodes but is still within one region, so a purge is a small, fast fan-out. - **The CDN** may have dozens to hundreds of globally distributed edge nodes, each independently caching, so a purge call has to fan out worldwide and can take anywhere from sub-second to tens of seconds depending on the provider, and individual edge purges can silently fail. ## Fan out from one event at the source of truth The disciplined way to reason about this is to trigger invalidation from a single event at the source of truth rather than four separate manual or ad hoc calls scattered through application code. A common pattern: 1. The price-update transaction, on commit, publishes a **domain event** (or is captured via change-data-capture off the database's write-ahead log) carrying the product ID and new price. 2. A dedicated invalidation consumer/service subscribes to this event and is solely responsible for fanning out: delete/update the `Redis` key, purge the specific reverse-proxy cache entries for that product's URLs, and call the CDN's purge API for the same URLs. Centralizing this avoids the failure mode where a developer remembers to invalidate Redis but forgets the CDN purge (or vice versa), which is exactly how 'the price shows differently depending on which server/region you hit' bugs happen in production. ## TTL backstops, and what to leave uncached Given that CDN and reverse-proxy purges are the least reliable link, every tier should also carry its own **TTL as a backstop**, sized according to the business tolerance for a stale price being shown — e.g., a CDN TTL of 60 seconds means that even if a purge is silently dropped, the worst case is a stale price shown for at most a minute, which is often an acceptable trade against building a bulletproof, low-latency global purge system. For strict correctness needs (e.g., final checkout price must never be wrong even briefly), the pragmatic answer is often to not cache that specific value at those outer tiers at all — bypass the CDN and reverse-proxy cache for the final price-confirmation step and read it live from `Redis` or the database, while still caching the merely-informational 'display price' on the product listing page with a short TTL and best-effort purge. This illustrates the principal-level judgment call: not every value needs the same caching aggressiveness, and the right architecture assigns each piece of data to the tier and staleness tolerance appropriate to its actual correctness requirement, rather than uniformly caching (or uniformly not caching) everything.