Caching Layers Explained: Browser, CDN, Reverse Proxy, and Application Cache

Caching Is a Stack, Not a Single Setting

Ask someone how to make their website faster, and the answer is often "add caching." But caching is not a single knob you turn. It is a layered system where each layer serves a different purpose, operates under different rules, and has different failure modes. Understanding where each layer fits — and what belongs at each level — is the difference between a well-cached site and one that either serves stale data or gains no benefit from caching at all.

This guide walks through the four primary caching layers in a typical hosting stack: browser cache, CDN edge cache, reverse proxy cache, and application-level cache. For each layer, you will learn what it does, when to use it, and the common pitfalls that cause problems.

Layer 1: Browser Cache

The browser cache is the closest cache to the user. When a browser downloads a resource — an image, a stylesheet, a JavaScript file — it stores a copy locally. On subsequent page loads, the browser checks whether it already has a cached copy before making a network request.

How It Works

Browser caching is controlled by HTTP headers sent from your server:

• Cache-Control: The primary directive. max-age=31536000 tells the browser to cache the resource for one year. no-cache means the browser must revalidate with the server before using the cached copy. no-store means the resource must never be cached.
• ETag: A fingerprint of the resource. When the browser revalidates, it sends the ETag back. If the resource has not changed, the server responds with 304 Not Modified, and the browser uses the cached copy without re-downloading it.
• Last-Modified: Similar to ETag but based on the file's modification timestamp.

Best Practices

For static assets with fingerprinted filenames (e.g., app.a1b2c3.js), set a long max-age — a year is standard. The fingerprint changes when the file changes, so the browser automatically fetches the new version. For HTML documents, use no-cache or short max-age values to ensure visitors always see the latest content.

Common Pitfall

Setting long cache lifetimes on non-fingerprinted assets means users might see stale versions for days or weeks after you deploy changes. Always pair long cache lifetimes with filename-based cache busting (hashing, versioning) for assets that change.

Layer 2: CDN Edge Cache

A CDN caches your content on edge servers distributed globally. When a visitor requests a resource, the nearest edge server checks its cache before forwarding the request to your origin server. This reduces latency (the content is geographically closer) and offloads traffic from your origin.

How It Works

CDN caching follows the same HTTP cache headers as browser caching, with additional CDN-specific headers for fine-grained control. The CDN respects your Cache-Control headers by default. Some CDN providers also support CDN-Cache-Control or Surrogate-Control headers that allow you to set different cache lifetimes for the CDN versus the browser.

What to Cache at the Edge

Static assets, public HTML pages, and API responses that are the same for all users. Never cache personalized content at the edge — user dashboards, authenticated API responses, shopping cart data. Serving one user's personalized content to another is a privacy disaster.

Cache Invalidation

When you deploy new content, you need the CDN to serve the updated version. Options include purging specific URLs, purging by cache tag, or purging the entire cache. Most CDN providers offer APIs for automated purging integrated into your deployment pipeline.

Layer 3: Reverse Proxy Cache

A reverse proxy sits in front of your application server and can cache responses before they reach the application. Nginx, Varnish, and similar tools are commonly used for this. The reverse proxy intercepts incoming requests, checks its cache, and returns cached responses without involving the application — saving CPU, memory, and database queries.

When to Use It

Reverse proxy caching is most valuable when your application generates dynamic pages that are the same for many visitors. A blog post, a product listing page, or a marketing page that changes infrequently but requires database queries to render is a prime candidate. Instead of hitting the application and database on every request, the reverse proxy serves the cached HTML.

Configuration Patterns

• Full page caching: Cache the entire HTML response. Best for content that is identical for all visitors and changes infrequently.
• Micro-caching: Cache responses for very short periods (1-5 seconds). This handles traffic spikes gracefully — during a surge, only the first request per second hits the application, and the rest are served from cache.
• Selective caching: Cache specific URL patterns while passing others directly to the application. Useful when some pages are cacheable (blog, marketing) and others are not (user dashboard, checkout).

Common Pitfall

Caching pages that contain user-specific data — session information, CSRF tokens, personalized content — serves one user's data to another. Set up cache rules carefully: bypass the cache for authenticated users, pages with cookies, and any URL that returns personalized content.

Layer 4: Application Cache (Redis, Memcached)

Application-level caching stores computed results in memory so the application does not have to recompute them on every request. Redis and Memcached are the two most common tools. This layer sits inside your application logic and caches database query results, API responses from external services, rendered template fragments, and computed values.

What to Cache

• Expensive database queries: If a query takes 200 milliseconds and the result does not change frequently, cache the result with a TTL that matches the data's freshness requirements.
• External API responses: If your page calls a third-party API, cache the response to avoid hitting rate limits and to reduce latency.
• Session data: Storing sessions in Redis instead of the filesystem improves performance and enables session sharing across multiple application servers.
• Computed values: Navigation menus, sidebar widgets, category counts — anything that requires multiple queries but changes infrequently.

Cache Invalidation Strategies

Application cache invalidation is the hardest part of caching. Common strategies:

• TTL-based expiration: Set a time-to-live on each cached value. After the TTL expires, the next request regenerates the value. Simple and predictable, but the data can be stale for up to one TTL period.
• Event-driven invalidation: When the underlying data changes (a blog post is published, a product price is updated), explicitly delete or update the relevant cache entries. More complex but ensures fresher data.
• Cache-aside pattern: The application checks the cache first. On a miss, it queries the database, stores the result in cache, and returns it. On a hit, it returns the cached result directly. This is the most common pattern for application caching.

How the Layers Work Together

The request flows from the user through each layer: browser cache → CDN edge → reverse proxy → application cache → database. Each layer that serves a cached response saves the layers below it from doing any work. A well-configured stack means that most requests never reach your application server at all — the CDN or reverse proxy handles them.

For a typical content website, the effective cache hit rates might look like this: browser cache handles 40-50% of asset requests (returning visitors), the CDN handles 30-40% (new visitors from cached edges), the reverse proxy handles a significant share of HTML page requests, and the application cache reduces database load for the requests that do reach the application.

Debugging Cache Issues

When caching goes wrong, the symptoms are confusing: stale content that will not update, different users seeing different versions, or no caching benefit at all. Debug by inspecting response headers at each layer. Check X-Cache headers from the CDN (HIT vs MISS), Cache-Control headers from the origin, and cache status headers from the reverse proxy. Tools like curl -I let you inspect headers directly without browser interference.

The Bottom Line

Effective caching is not about adding a single layer — it is about using the right layer for the right content. Browser caching for static assets. CDN caching for global delivery. Reverse proxy caching for dynamic pages that are the same for all visitors. Application caching for expensive computations and database queries. Configure each layer thoughtfully, respect cache lifetimes, and handle invalidation deliberately. The result is a site that is fast, resilient, and efficient — without serving stale or private data.