Caching Layers: Browser, CDN, Proxy, App & Database

Q: Where should I cache — at the edge or in the app?

As close to the user as is safe. Static, public content belongs at the CDN/edge for the biggest latency win. Dynamic or personalized data belongs in the application layer (e.g. Redis), keyed per user, where you control invalidation. Many systems use both.

Q: How is this different from "caching strategies"?

This page covers the layers (where caching physically happens across the stack). Caching Strategies covers the patterns — cache-aside, write-through, write-behind, invalidation, and stampede protection — that you apply at any given layer.

Caching Layers

Caching isn't one thing in one place — it happens at every layer between the user and your data: the browser, a CDN at the edge, a reverse proxy, your application, and the database itself. Each layer that serves a request means a faster response and less load downstream.

This page is the where of caching. For the how — cache-aside, write-through, invalidation, and stampede protection — see Caching Strategies, which this complements.

TL;DR

Cache at multiple layers: browser → CDN/edge → reverse proxy → application → database.
Push static, public content as close to the user as possible (the edge).
Cache dynamic/personalized data closer in (application/Redis), keyed per user.
Never cache private data in a shared layer.

Quick Example

HTTP cache headers let the browser and CDN cache an asset for a year while staying revalidatable:

The Layers

The rule of thumb: the further out (closer to the user) you can safely cache, the bigger the win — but the harder invalidation and personalization become.

Best Practices

Serve static assets from a CDN with long, content-hashed (immutable) cache lifetimes.
Use stale-while-revalidate to serve fast while refreshing in the background.
Cache dynamic data in the application layer (Redis) with deliberate keys and TTLs.
For SSR/HTML, cache only what's safe — public pages at the edge, personalized pages closer in (or not at all).
Track hit rate, latency (hit vs miss), evictions, and memory at each layer.

Common Mistakes

Caching private data in a shared layer

Caching errors or empty results

FAQ

Where should I cache — at the edge or in the app?

As close to the user as is safe. Static, public content belongs at the CDN/edge for the biggest latency win. Dynamic or personalized data belongs in the application layer (e.g. Redis), keyed per user, where you control invalidation. Many systems use both.

How is this different from "caching strategies"?

This page covers the layers (where caching physically happens across the stack). Caching Strategies covers the patterns — cache-aside, write-through, write-behind, invalidation, and stampede protection — that you apply at any given layer.

Can I cache server-rendered (SSR) pages?

Yes, carefully. Fully public pages can be cached at the CDN/edge; pages with per-user content must be cached per user (or not at all) to avoid leaking data. Splitting a page into a cacheable shell plus a personalized fragment is a common pattern.

How do I avoid serving stale data across layers?

Use short TTLs plus event-based invalidation for data that must be fresh, content-hashed filenames for static assets (so a new version is a new URL), and stale-while-revalidate where slight staleness is acceptable. Decide explicitly what must be strongly consistent versus "close enough."