CDN, Edge, and Reverse Proxy Caches

CDN, edge, and reverse proxy caches sit on the HTTP path between the user and the application. Because they are close to the caller and because they can cache complete responses, they often deliver the highest-leverage caching win in web systems. When they work well, the request never reaches the origin at all.

These caches are especially powerful because HTTP already has vocabulary for cacheability: status codes, headers, validators, Cache-Control, ETag, and revalidation semantics. The challenge is that HTTP-facing caches are also easy to misuse. One wrong header can accidentally make private data cacheable or make highly cacheable content effectively uncachable.

    flowchart LR
	    U["User"] --> C["CDN or edge cache"]
	    C --> R["Reverse proxy"]
	    R --> O["Origin application"]
	    C -. "serve cached response\nwithout origin trip" .-> U

Why It Matters

This layer matters because it can remove both geographic distance and origin work at once. Static assets, public pages, cacheable API responses, and media content can be served from infrastructure much closer to the user. That reduces latency, bandwidth concentration on the origin, and the risk that popularity spikes reach the application servers directly.

Where HTTP-Facing Caches Shine

These caches are strongest for:

• static assets
• public pages with shared responses
• API responses that can safely be cached by key and headers
• media or document delivery

They are less suitable for highly personalized responses unless the cache key includes the right variation dimensions and the privacy model is extremely clear.

HTTP Semantics Matter More Than Product Choice

With CDN and reverse-proxy caches, header design is often more important than the specific vendor. The core questions are:

• is the response public or private?
• how long may it be served without revalidation?
• what header dimensions vary the cache key?
• can the response be revalidated with ETag or Last-Modified?

If those answers are wrong, the cache becomes dangerous no matter how fast it is.

Example

This example shows a response policy for a public product detail page that can tolerate short-lived staleness and supports edge revalidation.

1Cache-Control: public, max-age=60, stale-while-revalidate=300
2ETag: "product-42-v17"
3Vary: Accept-Encoding

What to notice:

• public makes shared caching intentional
• max-age defines the fresh period
• stale-while-revalidate allows a smoother user experience during refresh
• Vary protects the cache key from collapsing incompatible representations

Common Mistakes

• caching private or user-specific responses in a shared layer accidentally
• forgetting the right Vary dimensions and mixing incompatible response variants
• setting headers so conservatively that the CDN never meaningfully helps
• assuming HTTP caches solve application-object caching automatically

Design Review Question

Why are CDN and reverse-proxy caches often the highest-leverage starting point for web performance?

The stronger answer is that they can prevent requests from reaching the origin entirely while also serving from infrastructure closer to the user. They remove both backend work and network distance, which is hard for deeper cache layers to match.

Quiz Time