CDN Caching

A CDN (Content Delivery Network) is a globally distributed set of cache servers — called POPs (Points of Presence) or edge nodes — that sit between users and your origin. When a user requests a resource, the DNS resolution routes them to the nearest POP (typically via anycast or EDNS client subnet). The POP serves the request from its cache if it has it; otherwise it fetches from the origin, caches the response, and serves it.

This is fundamentally a cache-aside pattern at the edge: read-through on miss, with TTLs governing freshness. But unlike application-level cache-aside, the CDN cache is geographically distributed — there is no single "cache node," there are hundreds. Each POP maintains its own cache, so the same resource may be cached in 200 different places, with 200 different TTL countdowns, and 200 different invalidation states.

CDN caching is the second layer in the standard cache hierarchy:

client cache → CDN edge → web server cache → app cache → DB cache → DB

The client cache is faster (zero network), but only the CDN can serve a first-visit user from a nearby POP. Client cache is invisible to the operator; the CDN is operator-controlled and observable. They are complementary: client caching handles repeat visits, CDN handles first visits and global latency.

TTLs: max-age vs s-maxage vs stale-while-revalidate.

CDN caching is governed by HTTP cache headers, but with an important nuance: the CDN (a shared proxy cache) has different TTL semantics than a browser (a private cache). The HTTP spec provides separate directives for each.

• Cache-Control: max-age=N — applies to all caches (browser AND CDN). The response is fresh for N seconds.
• Cache-Control: s-maxage=N — applies ONLY to shared caches (CDN, proxy). Overrides max-age for the CDN. Use this when you want the CDN to cache for a long time but the browser to revalidate frequently.
• Cache-Control: stale-while-revalidate=N — the CDN may serve stale content for up to N seconds while it revalidates against the origin in the background. This is refresh-ahead at the CDN layer: hot content never misses.
• Cache-Control: private — the response is user-specific; CDNs must not cache it (only the user's browser may).
• Cache-Control: public — explicitly allows shared caches to store the response (needed when basic auth would otherwise make the response uncacheable).

The classic pattern for static assets: Cache-Control: public, max-age=31536000, immutable — cache for a year, no revalidation, no conditional requests. Combined with versioned URLs (content-hashed filenames), this is the gold standard.

For API responses that change occasionally: Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60 — the browser revalidates every 60s, the CDN caches for 5 minutes, and the CDN may serve stale for an extra 60s while refreshing.

Origin shield — protecting the origin from cache miss storms.

If a piece of content suddenly becomes viral and many POPs miss at the same time, the origin can still see a burst of requests — one from each POP that just missed. For an origin at capacity, this can be enough to take it down. The standard mitigation is an origin shield: a single intermediate cache layer between the POPs and the origin.

POPs (hundreds) → origin shield (1-2 caches) → origin

When POPs miss, they fetch from the shield rather than the origin. The shield collapses concurrent misses: if 100 POPs all request the same URL within 100ms, the shield fetches from the origin once, then serves the result to all 100 POPs. The origin sees one request, not 100. CloudFront calls this a "shield," Fastly calls it an "origin shield," Akamai calls it an "edge origin." The pattern is universal.

Origin shielding also enables more aggressive caching of the cache-miss path: even a no-cache response (must revalidate every time) can be coalesced by the shield so that only one revalidation reaches the origin per interval. This is the same idea as single-flight / request coalescing for cache stampedes, applied at the CDN-to-origin hop.

When to use CDN caching:

• Static assets (JS, CSS, images, fonts, videos). Always.
• Public, slowly-changing data (product catalog, public profiles, landing pages). Short TTL or stale-while-revalidate.
• Global user base. If your users are in one region, an origin cache may be enough; if they are global, a CDN is essential.
• API responses that are public and cacheable (GraphQL persisted queries, public REST endpoints). Use s-maxage to keep the browser TTL short while the CDN caches longer.
• When you need DDoS protection. The CDN absorbs the traffic; the origin sees only misses.

When NOT to use CDN caching:

• User-specific, real-time data (live chat, real-time dashboards). private or no-store.
• POST/PUT/DELETE responses. CDNs cache GET and HEAD by default; non-idempotent methods are not cached.
• Single-region, low-latency apps where an origin cache would suffice. The CDN adds a hop for first-visit users.
• Highly dynamic content with strict freshness requirements and no stale-while-revalidate tolerance.

Mental model. Think of CDN Caching as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does CDN Caching mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose CDN Caching, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

A useful first-order model is cache_load = request_rate × (1 - hit_rate). If traffic is 20,000 req/s and the hit rate is 90%, roughly 2,000 req/s still reaches the origin before considering misses caused by expiration or eviction.