CDNs: What Every Engineer Should Actually Know

A CDN is more than "a cache in front of your site." Cache keys, invalidation, edge compute, and origin shielding are the parts that actually matter once you're debugging a production incident.

What a CDN is actually doing

A Content Delivery Network is a globally distributed set of edge servers (Points of Presence) that cache and serve content closer to end users, reducing latency and offloading your origin servers. That's the one-sentence pitch. The part most engineers skip past is how caching decisions are made — and that's where production incidents usually live.

Cache keys: the most important concept

Every cached response is stored against a cache key — by default usually the request URL, but configurable to include headers, query strings, or cookies. Get this wrong and you either over-cache (serving user A's personalised response to user B) or under-cache (treating ?utm_source=twitter as a different page from the canonical URL, destroying your hit ratio).

# Example: Cloudflare cache key customisation (Cache Rules)
# Include only specific query params in the cache key
cache_key = {
  "query_string": { "include": ["id", "lang"] },
  "header": { "include": ["Accept-Language"] }
}

Cache-Control headers: origin sets the contract

The CDN takes its cue from your origin's Cache-Control header. Getting these wrong is the single most common cause of "why is my CDN not caching" or its evil twin, "why is my CDN serving stale data for an hour after I deployed."

Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=60

• max-age — how long browsers cache it
• s-maxage — how long shared caches (the CDN) cache it, overriding max-age for the edge
• stale-while-revalidate — serve stale content instantly while refetching in the background, hiding origin latency from the user entirely

Invalidation: the other hard problem

"There are only two hard things in computer science: cache invalidation and naming things." Purging is slow and expensive at scale (especially wildcard purges); tagging content with cache tags/surrogate keys so you can invalidate precisely ("purge everything tagged product:1234") is almost always worth the upfront integration work over purging by URL pattern.

Origin shielding and the thundering herd

When cached content expires simultaneously across many edge nodes, they can all miss cache at once and hammer your origin — a thundering herd. Origin shielding routes all edge-to-origin traffic through a single designated shield PoP, so only one request reaches your origin per cache miss instead of one per edge location worldwide.

Edge compute: the CDN as a runtime

Modern CDNs (Cloudflare Workers, Fastly Compute, AWS CloudFront Functions/Lambda@Edge) let you run actual code at the edge — auth checks, A/B test routing, header rewriting, even full API responses — without a round trip to origin. This blurs the line between "CDN" and "platform," and is worth knowing about before reaching for a full origin round-trip for logic that could run in milliseconds at the edge.

Debugging checklist

• Check response headers: CF-Cache-Status, X-Cache, or equivalent — HIT, MISS, EXPIRED, BYPASS tell you exactly what happened
• Confirm the cache key actually matches what you expect (query strings, headers, cookies, device type)
• Check origin Cache-Control headers are what you think they are — not overridden by a proxy or framework default
• For stale content after deploy: confirm your deploy pipeline triggers a purge, and that it targets the right tags/URLs

Final thoughts

A CDN is infrastructure you interact with constantly but often reason about superficially. Understanding cache keys, header contracts, and invalidation strategy turns "the CDN is being weird" into a debuggable, predictable system — and often removes the need to reach for origin-side fixes at all.