Content Delivery Networks — Caching the Internet, Geographically

A CDN is a planet-scale distributed cache — thousands of servers placed physically close to users in every major city. Instead of every request traveling across the globe to your one origin server, it bounces off the nearest edge node. Latency drops from 150 ms to 10 ms. Your origin server handles 1% of the traffic it used to. But the magic is entirely in the details: how routing finds the nearest node, what the cache key includes, when to purge vs let TTLs expire, and where edge compute fits in.

Most engineers know CDNs make websites faster. Fewer can explain why in physics terms — and that understanding matters, because it tells you exactly how much faster a CDN can make your site (and where its limits are). The answer starts with the most unforgiving constant in nature: the speed of light.

The Physics Problem You Can't Optimize Away

Light travels at roughly 300,000 km/s in a vacuum. In fiber-optic cable, photons travel at about two-thirds of that — around 200,000 km/s — because glass slows them down (the refractive index of glass is ~1.5, so light takes 1.5× longer to traverse the same distance). That sounds fast, but the internet is big. The straight-line distance from New York to Sydney is about 16,000 km. The actual fiber path (which follows undersea cables, not straight lines) is longer — closer to 18,000–20,000 km. At 200,000 km/s, a single one-way trip takes:

That 160 ms is the floor. No amount of server optimization can push it below that — it's physics. And that's the best case. Real network paths add more latency from routing hops, queueing, and handshakes. Now consider what a web browser actually does when it loads a page:

• DNS lookup — ~50 ms (can be cached, but often isn't on first visit)
• TCP connection — 1 round trip = 160 ms (SYN → SYN-ACK → ACK)
• TLS 1.3 handshake — 1 additional round trip = 160 ms (TLS 1.2 was 2 round trips = 320 ms)
• HTTP request + first byte — 1 more round trip = 160 ms

Before the user sees a single byte of your page, the Sydney browser has burned 160 + 160 + 160 = 480 ms in round trips alone — with TLS 1.3. With TLS 1.2, it was worse. On mobile with higher base latency, worse still. The content download comes after all of that. A 200 KB HTML page at 10 Mbps takes another 160 ms to transfer. Total: easily 700–1,500 ms just to render the first screenful.

The Startup Story: Sydney Users Stop Coming Back

Here's how this plays out in practice. A startup launches its SaaS product with servers in US-East (Virginia). The founding team is in New York — pages load in 200 ms, feels snappy. They get their first customers in Australia via a product hunt launch. Those users experience 1.4-second page loads. The landing page bounce rate from Sydney is 68% vs 22% for US users. The team notices after three weeks when someone checks the analytics by country. They've lost hundreds of potential signups to a physics problem they didn't know existed.

A CDN with a Sydney edge node changes the math completely. The user's request hits the Sydney PoP — 10 ms away instead of 16,000 km. The TCP + TLS handshakes happen locally (10 ms × 3 round trips = 30 ms). The cached HTML is served in milliseconds. Total time to first byte: ~50 ms. Page load for Sydney users drops from 1.4 seconds to under 200 ms. Bounce rate normalizes.

The diagram makes it concrete. Without a CDN every user — regardless of where they live — waits for the full round trip to the origin. With a CDN, users hit the nearest edge and physics works in their favor instead of against them. The origin still exists and still handles cache misses (the first time any given resource is requested at an edge) but that's a rare event compared to the storm of cache hits.

The RTT Decomposition: Where Every Millisecond Goes

It's worth being precise about what "latency" means when a browser loads a page over HTTPS. Every component adds time, and most of them require round trips — which means every component is taxed by the propagation delay twice (out and back). Here's the breakdown for a first visit, NYC to Sydney, no CDN:

The key insight in that diagram: three of the five phases (TCP, TLS, HTTP request) are each a full round trip. Every round trip burns the propagation delay twice. A CDN doesn't speed up your server or your code — it shortens the round trip by moving the endpoint physically closer. That's why the CDN's impact is multiplicative: it cuts every round-trip-dependent cost by the ratio (edge RTT / origin RTT), not just one of them.

To reason about CDNs clearly, you need one mental model that explains the entire architecture. Here it is: a CDN is a three-layer cache pyramid. Data lives at the bottom in your origin, propagates up through an optional middle tier (the origin shield), and sits at the top in hundreds of edge PoPs distributed worldwide. Users at the very top request content; the request flows down the pyramid until it hits a cache layer that has the content, then flows back up.

Layer 1 — The Origin (Bottom)

The origin server is your application — an EC2 instance, an S3 bucket, a Kubernetes service. It's the single source of truth: when the CDN doesn't have a cached copy of something, it goes here. The goal of a CDN is to make origin requests rare. In a well-tuned CDN deployment, the origin handles under 5% of total traffic — the other 95%+ is served from edge caches. This matters because your origin is expensive: it runs your application code, queries your database, and costs money proportional to traffic. CDN origin offload directly reduces compute costs.

Layer 2 — The Origin Shield (Middle, Optional)

The origin shield is where things get clever. Imagine your CDN has 300 edge PoPs worldwide. If a popular new blog post is published, every edge PoP that gets a first request for that post will simultaneously send a cache-miss request to your origin. That's a thundering herd — 300 origin requests arriving at once. The origin shield is a single designated CDN PoP that sits between all the edge PoPs and your origin. Every cache miss from every edge PoP routes through the shield first. The shield checks its own cache — if it has the content, it serves all 300 edge PoPs from there (1 origin request total). Only if the shield misses does the request reach your origin. Cloudflare calls this "Tiered Cache", Fastly calls it "shielding", AWS CloudFront calls it "Origin Shield." Same idea everywhere.

Layer 3 — Edge PoPs (Top)

The edge PoPs are the part of the CDN closest to users. Each PoP is a data center with dozens or hundreds of servers running the CDN software. These servers cache content, terminate TLS connections, run edge compute (Cloudflare Workers, Lambda@Edge), and handle the volume. A large CDN like Cloudflare operates in 300+ cities worldwide; a smaller enterprise CDN might have 50–80 locations. The PoP nearest a user depends on routing — which is covered in S5. Users never connect directly to the origin; they connect to the nearest PoP, and the PoP deals with everything else.

Reading the pyramid from top to bottom: a user request first hits the nearest edge PoP. If the PoP has a cached copy (a cache hit), it responds immediately — 5–50 ms. If not (a cache miss), the request routes to the origin shield. The shield checks its cache — if it has the content, all the edge PoPs that missed can be filled from here without ever reaching the origin. Only if the shield misses too does the request reach the actual origin server. In a well-tuned deployment, the shield absorbs most of the misses and the origin sees a tiny fraction of total traffic.

Why the Shield Matters: The Thundering Herd Problem

Without an origin shield, cache misses can create a "thundering herd" — a sudden wave of requests all hitting the origin simultaneously. Imagine you publish a new blog post. Within seconds, CDN edge PoPs in 50 cities each get their first request for it. Each PoP misses its cache. Each one independently asks your origin for the page. Your origin gets 50 simultaneous requests for the same URL, all arriving within 100 ms of each other. If your origin can handle 20 req/s, you've just pushed it to 500 req/s for a second. With a shield, those 50 edge misses all route through the shield, which makes a single request to the origin. Origin load: 1 request. The shield pattern is especially important for video content (a viral video can trigger millions of edge misses per second) and for systems with limited origin capacity.

CDN documentation is full of terms that sound similar but mean very different things. Getting these wrong leads to misconfigured deployments. This section pins each term to a plain-English idea before adding the jargon label — read it once and the rest of the page will be clear.

Cache Mechanics

Cache key — When the CDN receives a request, it needs to check "do I already have a copy of this?" The cache key is the lookup string. By default it's the full URL — scheme + host + path + query string. Two requests with the same cache key are considered identical and the CDN serves the same cached response to both. Two requests that differ in even one query parameter get separate cache entries.

Cache hit vs cache miss — A cache hit is when the CDN has a cached response and can serve it without calling the origin. A cache miss is when it doesn't and must fetch from origin. The ratio of hits to total requests is the cache hit ratio (also called hit rate). A hit ratio of 90% means 90% of requests are served from cache without touching your origin.

TTL (Time-To-Live) — Every cached entry has a TTL, set by the Cache-Control: max-age=N response header. After N seconds, the cached copy is stale and must be re-fetched. A TTL of 86400 means entries are cached for 24 hours. A TTL of 0 means "don't cache at all."

Purge — Purge is the act of immediately deleting a cached entry before its TTL expires. When you deploy new content, you purge the old cached copies so the next request fetches the fresh version. Most CDNs expose a purge API; some charge per purge request.

Cache-fill — When a cache miss occurs, the CDN fetches the content from the origin and stores it. That fetch-and-store is called a cache-fill. After the fill, subsequent requests for the same key are served from cache until TTL expires.

Routing Terms

Anycast — Imagine a thousand servers all over the world raising their hands at once and saying "I'm at this address." When you mail a packet there, the postal service hands it to whichever one is closest. That's Anycast: many physically separated servers advertise the same IP address, and the internet's routing protocol (BGP) automatically picks the nearest one for each user. Used by Cloudflare and Fastly. The user doesn't have to know which PoP they're talking to — they just send requests to the CDN's IP and the network silently routes to the nearest match.

GeoDNS — Instead of one shared IP, each PoP has its own unique address, and a smart DNS server hands out the right one based on where the asker is. A DNS resolver in Tokyo asks for example.com and gets back the Tokyo PoP's IP; a London resolver gets the London PoP's IP. That's GeoDNS — geography-aware DNS, used historically by Akamai (CloudFront also relies heavily on latency-based DNS for steering, in addition to Anycast). It gives more explicit per-region control than Anycast, but failover is slower because DNS records have to expire before traffic reroutes.

BGP (Border Gateway Protocol) — The routing protocol that Anycast relies on. BGP is how internet service providers agree on how to route traffic between networks. When Cloudflare announces the same IP from 300 PoPs via BGP, every ISP's router directs traffic to the closest Cloudflare PoP — automatically, without any DNS involvement.

Cache Control Terms

Cache-Control header — An HTTP response header your origin sends to control how caches (browsers, CDNs, proxies) should cache the response. Key directives: public (any cache can store it), private (only the user's browser, not CDNs), max-age=N (TTL in seconds), no-cache (must revalidate before serving), no-store (never cache at all), immutable (content will never change, skip revalidation).

ETag and conditional GET — An ETag is a fingerprint of a response's content. When a cached entry expires, instead of fetching the full content again, the CDN sends a conditional GET with the old ETag. If the content hasn't changed, the origin returns a 304 Not Modified response (no body, just a header) — the CDN resets the TTL and serves the cached content. This saves bandwidth when content changes rarely.

Vary header — Tells the CDN "this response varies by this request header." For example, Vary: Accept-Encoding means the CDN should cache separate copies for gzip-compressed and brotli-compressed versions of the same URL. Vary: Accept-Language means separate copies per language. Overusing Vary fragments the cache and tanks hit ratios — a common misconfiguration.

Surrogate key (cache tag) — A CDN-specific extension where you tag responses with logical identifiers (e.g., product-1234) and then purge by tag instead of by URL. One tag can correspond to thousands of URLs. Fastly uses Surrogate-Key headers; Cloudflare uses Cache-Tag; Akamai uses Edge-Control with tags. This is the scalable way to invalidate — instead of enumerating every URL that contains product #1234's data, you purge the tag and every matching URL is invalidated.

Signed URL — A URL with a cryptographic signature appended as a query parameter. The CDN verifies the signature before serving the content, which allows you to grant time-limited or user-specific access to otherwise-private content without changing the underlying file. Used for video streaming, software download links, and gated content.

Performance Metrics

Request-hit ratio vs byte-hit ratio — Two different ways to measure cache effectiveness. The request-hit ratio measures what fraction of requests are served from cache — good for measuring how much you're offloading origin compute. The byte-hit ratio measures what fraction of bytes are served from cache — better for measuring bandwidth savings. A single uncached 4 GB video file can make your byte-hit ratio look terrible even if your request-hit ratio is 99%.

Edge compute — Running code at the CDN edge instead of at the origin. Edge compute platforms (Cloudflare Workers, Lambda@Edge) let you run JavaScript or WebAssembly at the edge. This means you can handle A/B testing, authentication, redirects, and request rewriting at the edge — responses in 5 ms, no origin round trip at all.

The diagram threads all the vocabulary terms into a single request flow: a request arrives at the edge PoP, the cache key is checked, a hit serves the response immediately (governed by TTL and ETag revalidation), a miss triggers cache-fill through the shield and origin, and a purge/surrogate-key deletion allows early invalidation before TTL expiry.

When a user's browser makes a request to your CDN-fronted domain, something has to steer that request to the nearest edge PoP. Two fundamentally different techniques exist for doing this: Anycast and GeoDNS. They look similar to the end user — both result in the request reaching a nearby edge — but the underlying mechanics, failure modes, and trade-offs are completely different.

Anycast: Let BGP Do the Work

Before the routing trick makes sense, here's the world it operates in. The internet isn't one network — it's a patchwork of thousands of separately-run networks (Cloudflare's, Comcast's, AT&T's, Amazon's, your university's) stitched together. Each separately-run network is called an Autonomous System (AS). The protocol they use to gossip among themselves about who can reach which addresses — basically a global "ask your neighbor for directions" system — is BGP (Border Gateway Protocol). Every AS broadcasts to its neighbors "I can reach these IP ranges," and packets travel from AS to AS following that chain of announcements until they arrive at their destination.

Anycast works by having the CDN announce the same IP address block from every single PoP via BGP. Cloudflare's edge nodes — whether in Tokyo, London, or São Paulo — all advertise the same IP range (e.g., 104.16.0.0/12). When a user sends a packet to 104.16.x.x, every router along the path makes a BGP routing decision: "which of my neighbors can reach this IP?" Since multiple neighbors can reach the same IP (because all of Cloudflare's PoPs advertise it), the router picks the one that's topologically closest — fewest hops, lowest cost. The result is that the packet naturally flows to the nearest Cloudflare PoP without any DNS trick or geographic lookup.

The key advantage: Anycast failover is instantaneous. If a PoP goes down, it stops advertising the IP in BGP, and within seconds (the BGP convergence time), all traffic shifts to the next nearest PoP. No DNS TTL to wait for. No geographic mapping to update.

GeoDNS: Return the Right IP Based on Location

GeoDNS takes a different approach. Instead of advertising the same IP everywhere, each PoP has its own unique IP. The CDN's DNS servers look at the location of the DNS resolver making the query and return the IP of the geographically nearest PoP.

When a user in Tokyo types example.com, their browser asks their ISP's DNS resolver to look up the address. The CDN's DNS authoritative server sees that the resolver is in Japan and returns the IP of the Tokyo PoP. A user in London gets the London PoP IP. The DNS layer is doing the geographic routing, not the network layer.

The complication: DNS resolvers are not always co-located with users. A company using Google's Public DNS (8.8.8.8, which resolves from Google's locations) might get routed to the wrong PoP because Google's resolver in South Carolina handles the query for a user in Germany. EDNS Client Subnet (ECS) is an extension that partially solves this by having resolvers pass along the user's IP prefix to the authoritative DNS, allowing more accurate geographic targeting.

Anycast is elegant precisely because it offloads routing intelligence to BGP — the same protocol that's been routing the internet since 1994. The CDN doesn't need geographic databases, DNS tricks, or complex control planes. The internet itself handles load balancing and failover. A PoP failure is handled in seconds as BGP routes converge around the gap.

GeoDNS works at the DNS layer: the CDN's authoritative name server consults a geographic IP database, maps the resolver's location to the nearest PoP, and returns that PoP's unique IP address. The browser then connects directly to that IP. GeoDNS gives more fine-grained control (you can map specific countries to specific PoPs, implement traffic splitting by region, or route different user segments to different origins) but failover is slower: DNS TTLs mean it can take minutes for traffic to shift away from a failed PoP.

Side-by-Side Comparison

In practice, modern CDNs often combine both: Anycast for routing packets to the nearest PoP quickly, with GeoDNS as a fallback or for specific routing policies. The distinction matters when you're choosing between CDN providers or debugging why traffic from a specific region isn't hitting the expected PoP.

The cache key is the single most important configuration decision you'll make for a CDN. Get it wrong and your hit ratio collapses — you can have a perfectly healthy origin, thousands of edge PoPs, and a completely broken CDN that serves every request from origin anyway. Most production CDN bugs trace back to cache key misconfiguration.

The Default Cache Key (and Why It's Often Wrong)

By default, most CDNs use the full URL as the cache key: scheme + host + path + query string. Two requests that differ in any part of the URL get separate cache entries. That sounds sensible — and for most things it is — but real-world URLs are full of noise that shouldn't create separate cache entries:

• UTM tracking parameters — ?utm_source=newsletter&utm_campaign=sale. Added by marketers to every outbound link. Each unique combination creates a new cache entry. A campaign with 50 UTM variants means 50 separate cache misses for the same page.
• Ad click IDs — ?gclid=... (Google Ads), ?fbclid=... (Facebook). These are unique per click — every single user who arrives via an ad gets a cache key that's never been seen before. Hit ratio for ad traffic: 0%.
• Session tokens in query strings — ?session=abc123. If someone passes auth tokens in the URL (which they shouldn't, but it happens), every session gets a unique cache entry. Origin load scales with active users instead of with unique URLs.
• Sort/filter parameters — ?sort=price&order=asc. These should create separate cache entries (different content), but ?sort=price&order=asc and ?order=asc&sort=price are the same content with parameters in different order — different cache keys by default.

The Random-Query-Parameter Disaster (with numbers)

Here's the concrete failure mode. Imagine a product page for /products/widget-42 that you've carefully cached for 1 hour. Cache hit ratio for that page is 95% — excellent. Then marketing launches a campaign. Every link in the campaign email looks like /products/widget-42?gclid=Cj0KCQiA4NWrBhD_ARIsAFCKg_... — with a unique gclid per user per click. The CDN treats every unique gclid as a new cache key. It fetches the page from origin for every single click. Your 95% hit ratio for that URL drops to 0% for all campaign traffic. If the campaign drives 100,000 clicks, your origin gets 100,000 requests for what is functionally the same page.

The diagram captures both sides of cache key design: accidental expansion (noise query params that create separate entries for what is functionally the same content) and intentional expansion (the Vary header, which tells the CDN to cache separate copies for genuinely different variants of the same URL).

How to Fix It: Cache Key Normalization

Every major CDN lets you customize which query parameters are included in the cache key. The fix for the gclid/utm disaster is to strip those parameters from the cache key — the CDN still receives the full URL (so analytics tracking still works), but it looks up the cache entry using only the meaningful parameters.

All three snippets do the same thing conceptually: they tell the CDN "when checking whether you have a cached copy of this request, look up by the meaningful URL parts only — ignore these noise parameters." The noise parameters are still forwarded to the origin on a cache miss (so analytics and attribution still work), but they don't create new cache entries.

The Vary Header: When Cache Key Expansion Is Intentional

Sometimes you do want separate cache entries for the same URL. The most common case is content encoding: a browser that supports Brotli compression should get the Brotli-compressed version of a file, while a browser that only supports gzip should get the gzip version. Both serve the same logical resource at the same URL, but the bytes are different. The Vary: Accept-Encoding response header tells the CDN "cache this URL separately per Accept-Encoding value."

But Vary needs careful use. Vary: User-Agent creates as many cache entries as there are distinct user-agent strings — thousands. Your cache fills with entries you'll never reuse. Vary: Cookie means every user gets their own cache entry — effectively disabling the cache for that URL. The rule: only Vary on headers whose values genuinely map to meaningfully different responses, and where the number of distinct values is small (2–10, not thousands).

When to Include Headers and Cookies in the Cache Key

By default, CDNs ignore request headers and cookies when building the cache key — because including them would mean every user with a different session cookie gets a unique cache entry (destroying the cache). But there are legitimate cases where headers should be in the key:

• Authorization header for semi-private content — if you have content that's specific to a role (e.g., "admin" vs "user"), you can include a normalized role header in the cache key. One cache entry per role, not per user. Never include the raw auth token — that creates a unique entry per session.
• Accept header for API responses — if your API returns JSON for Accept: application/json and HTML for Accept: text/html, include Accept in the cache key (Vary: Accept in the response is the right mechanism).
• Device type for responsive CDN — if you serve genuinely different HTML for mobile vs desktop (not just CSS changes), you can add a normalized X-Device-Type: mobile|desktop header and include it in the cache key. Two entries per URL instead of thousands.

Before a CDN can cache anything, it needs instructions. Those instructions arrive as HTTP headers that your origin server sends with every response. Think of them as a contract: your server tells every cache in the world — browser caches, CDN edges, proxy servers — exactly how long to keep the response, whether to share it with other users, and how to check if the content is still fresh. Get this contract right and your CDN edge hit ratio is 90%+. Get it wrong and the CDN becomes an expensive pass-through layer that adds latency instead of removing it.

Cache-Control: The Master Directive

The most important header is Cache-Control. It's a comma-separated list of directives, each controlling one aspect of caching behavior. Here is a real production header and what every piece means:

Let's unpack each directive. The distinction between max-age and s-maxage is where most engineers get tripped up — they look similar but apply to completely different caches:

• public — this response may be stored by any cache, including shared caches like CDN edges. Without this (or with private), a CDN must not cache it. WHY: HTTP distinguishes private caches (your browser) from shared caches (CDN, proxy) because some responses contain personal data — a bank statement should never sit on a CDN edge where other users could retrieve it.
• max-age=3600 — browsers (and any cache that doesn't have a more specific instruction) should consider this response fresh for 3,600 seconds (1 hour). After that the browser revalidates. WHY: giving browsers a TTL means repeated page visits don't hit the network at all — the response comes from local disk cache in milliseconds.
• s-maxage=86400 — shared caches (CDN edges specifically) should consider it fresh for 86,400 seconds (24 hours). This overrides max-age for shared caches. WHY: you often want the CDN to hold content longer than the browser does. A browser cache miss hits the CDN (still fast), but a CDN miss hits the origin (expensive). So CDN TTL is set longer to maximize edge hits while browsers revalidate more frequently to avoid showing stale content.
• immutable — the content will never change while it's fresh; don't bother revalidating even if the user force-refreshes. WHY: JS bundles named with a content hash (e.g., app.a1b2c3.js) literally cannot change — if the content changes, the filename changes. Browsers were wasting network requests revalidating these on every user-initiated reload before immutable was introduced.
• private — only the user's own browser may cache this. CDN edges must pass it straight to the origin and never store it. This is the killer misconfiguration: a developer adds private to a cacheable product page because they're worried about user-specific data, and their CDN cache hit ratio drops to 0% overnight.
• no-cache — confusingly, this does NOT mean "don't cache." It means "cache it, but always revalidate before using it." A conditional GET (with If-None-Match) is sent on every request; if the origin confirms nothing changed, a 304 comes back instantly. WHY this exists: you want the speed benefit of revalidation (304 is tiny, no body) while guaranteeing users never see stale content for even a second.
• no-store — this one actually means "don't cache, ever, anywhere." For genuinely sensitive data (bank transactions, medical records). The CDN forwards every request to the origin, adding its own latency overhead.
• must-revalidate — once the TTL expires, caches must not serve the stale version even if the origin is down. WHY: for financial or safety-critical data where serving outdated information is worse than serving an error. Contrast with stale-if-error (Section 8) which does the opposite.

The decision tree above maps the most common scenarios. The critical fork is that very first question — user-specific or not? Developers often set private "just to be safe" on pages that are actually shared content. That conservative choice costs every user a full origin round trip on every request.

ETag and Conditional GETs — How "Not Modified" Works

An ETag (entity tag) is a fingerprint for a response body — usually a hash of the content or a version identifier. The origin sends it in the response. Later, when the cached copy is about to expire, the edge (or browser) sends back that fingerprint in a request header called If-None-Match. If the content hasn't changed, the origin replies with 304 Not Modified — no body, just headers. This is the cheapest possible cache refresh: you get confirmation the content is still valid for almost zero bandwidth cost.

Here is the actual three-step wire conversation. Read it as a script with three lines spoken by two computers:

In the first block, the origin says "here's the full 45 KB response, and its fingerprint is a1b2c3d4e5f6 — cache it for a day." The edge stores both the bytes and the fingerprint. A day later, when the TTL is about to expire, the edge doesn't ask "give me everything again" — it asks "do you still have that same fingerprint?" by sending the If-None-Match header. In the third block, the origin checks its own current fingerprint, sees it matches, and replies with just 304 Not Modified — no body at all. Forty-five kilobytes of bandwidth saved on what is effectively a "still valid, carry on" handshake.

The 304 flow is the unsung hero of web performance. The edge re-confirms freshness for almost no cost — just headers, no body. Compare this to no ETag: without a fingerprint to compare, the origin must send the full 45 KB body every time the TTL expires, even if nothing changed. For high-traffic APIs this difference is significant.

Vary: Teaching the CDN About Variants

Here's a subtle but important problem. Your origin serves gzip-compressed responses to browsers that support it, and uncompressed responses to old clients. The URL is identical: GET /api/data.json. But the response bodies are completely different. If the CDN caches the gzip version and serves it to a client that can't handle gzip, that client gets garbage bytes. The fix is the Vary header.

Vary: Accept-Encoding tells the CDN: "the response varies based on the Accept-Encoding request header, so cache a separate copy for each distinct value." The CDN splits its cache: one entry for Accept-Encoding: gzip, another for Accept-Encoding: br (Brotli), another for clients that send no encoding preference.

The warning at the bottom of the diagram is real. Vary: Cookie is the classic disaster. Every unique cookie value creates its own cache entry. Since session cookies are unique per user, the CDN effectively cannot cache anything — it stores one entry per user per URL and never gets a hit. Most CDNs (Cloudflare, CloudFront) strip or ignore Vary: Cookie entirely on cacheable responses to prevent this; others let it explode your cache storage. Know your CDN's behavior before you ship Vary.

TTL — Time To Live — is the number most engineers know. Set s-maxage=86400 and the CDN serves your content for 24 hours, then discards it and asks the origin again. Simple. But in production, a naive TTL creates a brutal binary: content is either fully cached (fast) or fully expired (origin hit). There's no middle ground. The middle ground is what stale-while-revalidate and stale-if-error provide — and once you understand them, you won't want to operate without them.

The TTL Problem: The Thundering Herd at Expiry

Imagine your homepage has a 60-second TTL and receives 10,000 requests per minute. At second 61, the TTL expires. Now every incoming request simultaneously finds a stale cache entry. All 10,000 requests/minute want to know: "is this still fresh?" The CDN serializes them — one request triggers a refetch to the origin, and the others either wait (request coalescing, if the CDN supports it) or all hammer the origin at once (the thundering herd problem). Your origin goes from handling zero requests to handling 10,000 requests/minute in an instant, every 60 seconds like clockwork. This is why systems built with only TTLs sometimes have spiky origin load that looks mysterious on a dashboard.

stale-while-revalidate: Serve First, Refresh in Background

The solution is a behavior called stale-while-revalidate, standardized in RFC 9111 (previously RFC 5861). Here's the idea in one sentence: after the TTL expires, keep serving the old cached copy to users while simultaneously sending a background refresh request to the origin. The user gets instant response (no waiting), and the cache silently updates for the next request. Nobody waits. Nobody thunders.

Reading this header: the CDN caches the response for 60 seconds (s-maxage=60). After 60 seconds, the entry is "stale." For the next 30 seconds (stale-while-revalidate=30), when a request comes in the CDN does two things simultaneously: it serves the stale cached copy immediately (zero latency penalty), AND fires a background GET to the origin to fetch a fresh copy. Once the fresh copy arrives, it replaces the stale one. Users in that 30-second window never experience a cache miss — they see a response that might be up to 90 seconds old at most, but they get it instantly.

The impact of that last line is significant. Without stale-while-revalidate: every 60 seconds, up to N concurrent requests hit the origin. With it: the origin gets exactly one request every 60 seconds, while all user-facing requests are served at cache speed. This is especially powerful for news sites, dashboards, or APIs where content changes frequently but millisecond-freshness is not required.

stale-if-error: Your Origin Goes Down, Your Site Stays Up

The second resilience directive is stale-if-error. The premise: your origin server is having an incident. It's returning 500s, timing out, or simply unreachable. Normally, a CDN edge that can't reach the origin returns a 502 or 503 to the user. With stale-if-error, it instead serves whatever cached copy it has — even if that copy is past its TTL — for up to N additional seconds. Your users see slightly stale content instead of an error page.

Reading this: fresh for 5 minutes; if the origin fails, serve stale content for up to 24 hours. For most websites — blogs, marketing pages, documentation, product listings — showing content that's 4 hours old during an incident is vastly preferable to showing a 503 error page. Users can still browse. Conversion doesn't crater. The incident becomes invisible to most visitors.

This diagram illustrates why stale-if-error is sometimes called "poor man's high availability." It won't help you if the content absolutely must be current (a live stock price, a flash sale countdown), but for the vast majority of web content it turns an origin incident from a user-visible outage into a silent degradation. Cloudflare, Fastly, and AWS CloudFront all support this directive natively (CloudFront added support for both stale-while-revalidate and stale-if-error in May 2023).

Setting a long TTL is the right call for performance — it keeps content at the edge for hours or days and slashes origin load. But long TTLs create a problem: what happens when the content actually changes? A product price updates. A blog post is corrected. A security vulnerability in a JavaScript file requires an emergency patch. You can't wait 24 hours for the CDN to notice. You need to invalidate the cached copy immediately. Three techniques exist, each with different speed, cost, and complexity trade-offs.

Method 1: URL Purge — Simple but Slow

The most obvious approach: tell the CDN "delete the cached copy of this specific URL." Every major CDN exposes an API for this. Here's what it looks like for Cloudflare:

Reading the call line by line: you POST to a Cloudflare endpoint scoped to your zone (your domain); the bearer token authenticates you; the JSON body lists the exact URLs you want gone. The CDN receives this request and tells every edge node to drop those URLs from their cache. The next request for each URL will miss the cache and fetch fresh content from the origin.

The downside is propagation time. Cloudflare advertises purge propagation in "under 30 seconds" globally. Fastly is typically faster (closer to 150 ms in many cases). AWS CloudFront's invalidation is well-known to be slower — documentation says propagation can take "up to 15 minutes," though in practice it's often under a minute. The key point: URL purge is not instantaneous. During propagation, some edge nodes have the old content and some have triggered new fetches. For a product price change this delay is usually fine. For a critical security patch, you may also want method 3 (cache-busting URL) as a belt-and-suspenders approach.

URL purge also has a scaling problem: if your product catalog has 500,000 URLs and a supplier updates their entire inventory, you'd need 500,000 purge API calls. CDNs rate-limit these (Cloudflare allows 30,000 files per purge call but each call counts toward API rate limits). For bulk invalidation, you need something smarter.

Method 2: Surrogate Keys / Cache Tags — Fast and Surgical

Instead of targeting URLs, you tag cache entries at fill-time with logical identifiers, then purge by tag. The origin adds a special header to responses that groups related resources together. Here's Fastly's flavor (called Surrogate-Key) and Cloudflare's flavor (called Cache-Tag):

Both blocks attach tags to the response at the moment it's cached. Fastly takes space-separated tags in a header called Surrogate-Key; Cloudflare takes comma-separated tags in a header called Cache-Tag. The CDN stores these tags as metadata next to the cached object — the user's browser never sees them (the CDN strips them before forwarding). Now the product page, the category page listing shoes, and the inventory widget are all stamped with product-42. When the product's price changes, a single API call purges everything tagged product-42 — regardless of how many URLs that covers. This is the "fan-out purge": one tag, thousands of URLs, propagated globally in under a second on Fastly and Cloudflare.

This is the preferred method for large e-commerce sites, news platforms, and any CMS-backed site where content is structured and taggable. The CDN only holds these tags internally — users never see them in responses (CDNs strip Surrogate-Key and Cache-Tag before forwarding to browsers). The tag is purely a CDN-internal grouping mechanism.

Method 3: Cache-Busting URLs — Instant and Zero-Config

The third approach sidesteps invalidation entirely: if a resource changes, change its URL. The old URL stays in the CDN cache and ages out via TTL (nobody requests it anymore). The new URL cold-starts its own cache entry with fresh content. No purge API call required. No propagation delay. No CDN-specific configuration.

Look closely at the two <script> tags. The filename in each one literally contains a fingerprint of the file's contents (a1b2c3 before, d4e5f6 after). When even one byte of the JavaScript changes, the build tool computes a new fingerprint and emits a new filename. The HTML page that references the script gets re-rendered with the new filename, so browsers and CDN edges naturally request the new URL — guaranteeing they fetch the new content. No purge call needed; the URL itself is the invalidation signal. Modern build tools (Webpack, Vite, esbuild, Parcel) do this automatically — they hash file contents and embed the hash in the filename. The HTML that references these files is itself a short-lived asset (often with a TTL of 5 minutes or less). So the pattern is: static assets get a very long TTL (1 year is common: max-age=31536000, immutable) because the URL guarantees freshness; the HTML gets a short TTL and is the only thing you ever need to purge.

In production, the three methods combine: cache-busting URLs for all static assets (JS, CSS, images, fonts) with max-age=31536000, immutable; surrogate keys for HTML and API responses with short-to-medium TTLs; URL purge as a manual escape hatch for edge cases. The combination means your CDN hit ratio stays high (long TTLs on the majority of traffic) while updates propagate correctly (surrogate key purge on content changes).

Caching static and semi-static content is what CDNs were built for. But modern applications need more than that: they need to run logic — checking a JWT, picking an A/B test variant, redirecting mobile users, personalizing a cached page — before serving a response. The old answer was: send the request to the origin for the logic, then maybe cache the result. The new answer is: run the logic at the edge, inside the CDN itself, with no origin round trip at all. This is edge compute.

The idea is to deploy tiny functions — not full application servers — to every CDN edge node simultaneously. A user in Tokyo gets their logic executed in Tokyo. No request crosses the Pacific. The function runs in under a millisecond, produces a response, and the user is none the wiser that there was no "backend" involved. For the right use cases this is transformative: you get origin-level logic at CDN-level latency.

The diagram captures the key shift: with edge compute, the CDN edge stops being a pure cache layer and becomes a thin application layer. Logic that used to require an origin round trip now runs 10–20 ms from the user, regardless of where the origin lives. The origin still handles database queries and business-critical writes, but the stateless, logic-only work moves to the edge.

The Three Platforms Compared

Edge-Side Includes: Composing Cached Pages with Dynamic Fragments

One more edge compute capability worth knowing: Edge-Side Includes (ESI). The idea is to serve a mostly-cached HTML page but "punch holes" in it where dynamic, user-specific fragments go. The edge fetches the dynamic fragment (from a fast backend API) and stitches it into the cached page before delivering to the user.

The edge caches the outer HTML for an hour (avoiding expensive origin renders) while injecting fresh inventory and cart data per-request from fast microservices. The user sees a complete, personalized page with accurate inventory — but 95% of the content came from the CDN cache. ESI is supported natively by Varnish and Fastly, and can be implemented in Cloudflare Workers via custom logic.

CDN pricing looks deceptively simple until your first invoice. There are three independent dimensions being charged, and the relative weight of each depends entirely on your traffic profile. A video streaming service cares almost entirely about bandwidth. A high-frequency API cares primarily about request count. A serverless edge platform cares about compute time. Pick the wrong CDN for your workload and you pay 5–10× more than you should.

The Three Pricing Dimensions

Bandwidth (per GB egress) — the amount of data transferred from CDN edge nodes to end users. This is the dominant cost for most sites. A video file of 500 MB served to 100,000 users costs 50 TB of egress. At even modest per-GB rates that adds up quickly. Bandwidth pricing typically tiers down as volume increases — the first 10 TB is more expensive per GB than the next 40 TB. WHY: CDNs have fixed infrastructure costs but marginal bandwidth costs drop at scale, so they pass some savings to volume customers.

Requests (per million) — some CDNs charge separately for each HTTP request regardless of response size. A site serving a large HTML page as a single request costs less here than a site serving 150 small resources (JS chunks, API calls, images) per page load. Request pricing matters enormously for image-heavy sites, SPAs with many small JS bundles, and APIs with frequent small payloads. A CDN that looks cheap on bandwidth can be expensive on requests if your traffic pattern is many-small rather than few-large.

Edge compute (per invocation / CPU time) — each edge function execution costs money. Cloudflare Workers Free tier gives 100,000 requests/day at no cost; paid plans charge per million requests above the included quota. Lambda@Edge charges per request and per 1 ms of compute duration (rounded up). These costs are usually small relative to bandwidth for typical workloads, but a CPU-heavy Worker that runs 10 ms per request on millions of requests per day can accumulate meaningful cost.

Provider Comparison (Approximate Public List Prices)

The prices below are approximate and sourced from publicly available list pricing at time of writing. Actual pricing varies by volume, region, contract, and changes over time — always check the provider's current pricing page before making decisions.

The Hidden Cost: Double-Paying on Cache Misses

There's a billing trap that catches engineers who don't think carefully about cache hit ratio. When a CDN cache misses, the edge fetches the resource from your origin. That origin fetch traverses the public internet (or your cloud provider's network). You pay twice: once for the CDN's egress delivering the response to the user, and once for the origin's egress delivering the resource to the CDN edge. If your CDN cache hit ratio is only 40%, then 60% of all traffic incurs double egress cost. For AWS users this is especially visible: CloudFront has no data transfer cost for requests from CloudFront to S3 or EC2 in the same region — but a CDN miss that pulls from an EC2 origin in a different region incurs EC2 egress charges on top of CloudFront charges.

The chart makes it visual: hit ratio is not linear in its impact on cost. Going from 60% to 90% hit ratio reduces origin load from 40% to 10% — a 4× reduction. Going from 90% to 99% reduces it from 10% to 1% — another 10× reduction. The majority of CDN cost optimization effort should focus on identifying why cache hit ratio is low (misconfigured Cache-Control, query parameter pollution in cache keys, excessive Vary headers) and fixing it. Each percentage point of hit ratio improvement reduces both latency and bill.

You've seen what CDNs do at a high level. Now let's trace a single HTTP request from the moment a user types a URL to the moment pixels appear on screen — microsecond by microsecond. Understanding this flow is what separates engineers who configure CDNs competently from engineers who diagnose CDN problems quickly.

The Full Request Path — Cache HIT

The happy path: the content is already cached at the nearest edge node. Here is the complete sequence:

1. DNS resolution — the user's browser resolves cdn.example.com. The authoritative DNS server returns either an Anycast IP (same IP globally, BGP routes to nearest PoP) or a GeoDNS response (different IP per geographic region). This takes ~10–50 ms on first lookup, near-zero from local DNS cache on repeat visits.
2. TCP + TLS handshake to the nearest edge — the browser opens a TCP connection to the resolved IP. Because it's Anycast/GeoDNS, this hits the nearest CDN PoP, not the origin. For a Sydney user, this might be 10 ms. TLS 1.3 adds one more round trip (~20 ms). Total handshake: ~30–40 ms.
3. HTTP request arrives at edge node — the edge receives the request. It hashes the cache key (URL, possibly normalized query params, possibly Accept-Encoding variant) and looks up the result in its local memory and SSD cache. Modern CDN edges hold gigabytes of cache per node in a tiered storage hierarchy: hot content in DRAM, warm content in NVMe SSD.
4. Cache HIT: respond immediately — if the cache entry exists and is within TTL, the edge returns it directly. Time from request arriving at edge to response sent: single-digit milliseconds for small objects in DRAM cache. The origin is never contacted. Total time-to-first-byte for the Sydney user: ~40–60 ms.

The Full Request Path — Cache MISS with Shield Tier

The less-happy but still-good path: the content isn't in the nearest edge's cache. Without a shield tier, the edge goes directly to the origin. With a shield tier, there's an intermediate step — and it's a powerful one.

A shield tier (also called an "origin shield") is a second, smaller layer of CDN nodes that sits between edge nodes and the origin. Instead of every edge PoP going independently to the origin on a miss, they all forward misses to the shield tier first. The shield has a larger, more persistent cache. If the shield has the content, it returns it and the origin is spared. If the shield also misses, only the shield fetches from origin — not every edge PoP simultaneously. Cloudflare calls this Argo Tiered Caching; Fastly calls it Origin Shield; AWS CloudFront has a feature also called Origin Shield.

The shield tier multiplies the origin-offload effect dramatically. Here's the arithmetic the diagram summarizes: suppose your CDN has 300 edge PoPs, and your edge cache hit ratio is 90%. Without a shield tier, 10% of all requests escape to the origin — and each of those 300 edges independently fetches from origin on a miss, meaning the origin potentially handles up to 30 simultaneous fetches for the same popular resource during a traffic burst. With a two-tier cache, those 300 edge misses collapse into a handful of shield requests. If the shield hit ratio is 80% (of misses), the origin sees only 2% of total traffic instead of 10%. One line of CDN configuration — enable Origin Shield — achieves a 5× reduction in origin load.

Putting It All Together: A Complete First-Visit Flow

Here is the complete sequence for a first visit to a page that isn't cached anywhere yet:

1. User opens browser → types URL → presses Enter. Browser checks local DNS cache (empty on first visit), asks OS resolver, which asks recursive resolver, which asks authoritative DNS. Returns Anycast IP. ~50 ms.
2. Browser opens TCP connection to Anycast IP. BGP routing in the internet's backbone steers the SYN packet to the nearest CDN PoP. TCP SYN-ACK round trip: ~10–20 ms for a nearby user.
3. TLS 1.3 handshake. One additional round trip, same ~10–20 ms. CDN edge presents TLS certificate (CDN manages certificates for your domain automatically).
4. Browser sends HTTP GET. Edge receives it, computes cache key, checks local DRAM and SSD cache. MISS — content not cached at this edge yet.
5. Edge forwards to shield tier (if configured). Shield checks its larger, more persistent cache. MISS — also not cached (first ever request).
6. Shield sends GET to origin. Origin receives the request, renders the page or reads from its database, and returns the full response with Cache-Control: public, s-maxage=300, stale-while-revalidate=60. This leg might take 50–200 ms depending on origin complexity.
7. Shield receives response, stores a copy keyed by URL + Vary dimensions. Forwards response to edge.
8. Edge receives response, stores a copy in its local cache (DRAM for hot content). Forwards to browser.
9. Browser receives and renders. Total time-to-first-byte: ~200–400 ms for first visit, depending on distance and origin response time.
10. Second request to same edge (any user worldwide within TTL): steps 1–4 only, cache HIT at step 4. Total TTFB: ~40–60 ms. No origin contact.

Here's the most reliable CDN pattern in existence: never change a URL — change the URL itself. It sounds like a riddle, but it's behind almost every high-performance web app you've used. Let's unpack what that means and why it works so well.

The Problem with Mutable URLs

Imagine you have a JavaScript file at https://example.com/static/app.js. You want the CDN to cache it for a long time so users don't re-download it on every visit. You set Cache-Control: max-age=86400 (one day). But now you deploy a bug fix. The URL is the same — app.js — but the content has changed. Every user whose browser (or the CDN edge) cached the old version will serve the broken code for up to 24 hours. You have two bad options: either set a short TTL (constant re-downloading, killing your CDN hit ratio) or set a long TTL and accept stale content for hours after deploys.

This is the classic cache invalidation problem — the notorious "one of the two hard things in computer science." The elegant solution modern build tools use sidesteps it entirely by making the URL encode the content itself.

Content Hashing: Baking the Fingerprint Into the Filename

Modern build tools like Webpack, Vite, and Next.js compute a content hash — a short cryptographic fingerprint of the file's bytes — and embed it in the filename at build time. The result looks like:

The hash (a3f7c291, 9e4b12d0, etc.) is derived directly from the file content via a fast hashing algorithm like MD5 or SHA. If a single byte of app.js changes, the hash changes completely (avalanche effect), producing a new filename. If the content is identical across deploys — for example, a library you haven't touched — the hash stays the same and the CDN re-uses the existing cache entry.

Now the magic: because the filename IS the content, you can set a permanent cache TTL with no risk of serving stale files. If the file changes, it gets a new URL — a fresh cache miss — and the new version is fetched. If the URL is already in cache, you know with mathematical certainty the cached version is correct.

The immutable directive tells browsers and CDN edges: don't bother checking for updates on this URL even when the max-age hasn't expired yet. Some browsers (Firefox, Chrome) honour this by skipping the conditional revalidation request entirely on back-navigation — a real speed boost for returning users.

The diagram above shows the full flow. Source files enter the build tool, which computes a content hash and bakes it into each output filename. The CDN caches these with a one-year TTL. On redeploy, the old hashed URLs sit quietly in cache until they naturally expire (browsers won't request them because the HTML now references new filenames). The new hashed URLs are fetched once — a cache miss — then cached for another year. The origin handles exactly one request per unique asset per CDN edge, no matter how many millions of users hit the page.

The Critical Exception: HTML Has a Short TTL

There's one file that can't be content-hashed: your HTML pages. HTML is the index that references all those hashed asset URLs. If you cache HTML for a year and then deploy new assets, users will fetch the old HTML — which points to the old hashed filenames — and your perfectly valid new assets will never be seen. HTML must have a short TTL so browsers and CDN edges revalidate it quickly after each deploy.

This two-tier strategy is the foundation of every serious CDN deployment for web assets. HTML gets a short TTL (60 seconds to a few minutes, plus stale-while-revalidate so returning users don't wait for the revalidation). Hashed assets get a one-year immutable TTL. The practical result: after a deploy, a user might see the old HTML for up to 60 seconds — but once their browser fetches the new HTML, all new asset URLs are cold cache misses and they get the fresh code immediately. Meanwhile, unchanged assets are served from the CDN's cache without touching origin at all.

Video is the heaviest workload a CDN handles. A single user watching a 1080p stream consumes 5–8 Mbps continuously for as long as they watch. Multiply that by millions of concurrent viewers during a live event and you're moving petabytes per second globally. The CDN techniques for video are fundamentally different from static file caching — and understanding them explains why modern streaming services can scale to any audience size.

The Core Idea: Chop the Video Into Tiny Pieces

Serving a 2-hour movie as a single 6 GB file would be catastrophic for caching. Every edge would have to store the whole thing. Users who seek to the middle would have to download from the beginning. Bandwidth would be wasted on content the user skips. Instead, two dominant streaming protocols exist — both built on the same insight: split the video into short segments and serve each one as a regular HTTP request.

Apple's flavor of this splitting trick is HLS (HTTP Live Streaming). It chops video into segments of 2–10 seconds each (stored as .ts files in a format called MPEG Transport Stream) and creates a small text file called a manifest — basically a playlist (.m3u8) that lists the segments in order. The browser or mobile app downloads the manifest first, then fetches segments one by one, staying a few segments ahead of playback so the user never sees a buffering pause. HLS is natively supported on iOS and Safari and is the protocol behind almost all mobile streaming in the US.

The vendor-neutral version of the same idea is DASH (Dynamic Adaptive Streaming over HTTP) — an ISO/IEC standard. DASH works identically in concept but uses .m4s segments (fragmented MP4 format) and an .mpd manifest. Because it isn't owned by any single company, YouTube, Netflix, and most non-Apple platforms standardized on it.

Both protocols produce the same architecture at the CDN level: thousands of small HTTP requests, each cacheable independently. This is the key insight that makes CDN video delivery work.

This .m3u8 manifest for a 2.4-hour movie lists 1,440 segments (at 6 seconds each). Each segment is a cacheable HTTP object. Once a segment is cached on a CDN edge, every user who watches that part of the video from that edge gets it from cache — zero origin requests after the first viewer.

The diagram shows the full pipeline. A video encoder produces multiple ABR (Adaptive Bitrate) variants of each segment — the same 6-second clip encoded at 1080p, 720p, 480p, and 240p. All variants are pushed to origin storage. The CDN caches each segment independently. The player fetches the manifest, measures its download speed for recent segments, and requests whichever bitrate it thinks its connection can handle without buffering. If you're on a fast Wi-Fi connection, you get 1080p. If you duck into a tunnel and bandwidth drops, the player smoothly steps down to 480p for a few segments, then steps back up when you emerge. No buffering, seamless transitions.

Byte-Range Requests: Seeking Without Re-Downloading

Even with segments, users sometimes seek to a specific timestamp inside a segment. HTTP byte-range requests — the Range: bytes=X-Y header — let a browser ask for only a portion of a file. CDNs support this natively: if the full segment is already in cache, the CDN slices out the requested byte range locally without asking origin. If the segment isn't cached yet, the CDN fetches it from origin and simultaneously stores the full segment in cache for future requests.

The Scale Numbers

A popular livestream event can fan out to millions of concurrent viewers within minutes. With a traditional origin-per-viewer model, you'd need millions of simultaneous connections to a single server — impossible. With CDN-based HLS delivery, origin ingests one stream and pushes it to the CDN. The CDN's edge nodes replicate segments locally. When a million viewers in Tokyo all request the same segment, the Tokyo PoP serves it from its local cache — origin sees at most one request per segment per PoP. If there are 300 PoPs globally and 1,440 segments in a 2.4-hour event, origin handles at most 432,000 segment fetches total, regardless of viewer count. Viewer counts beyond that are essentially free from an origin perspective.

Most teams think CDN = static files. That's half the story — and the less interesting half. Modern CDNs also dramatically accelerate dynamic content: API responses, personalized HTML, search results, and even entire page renders. If you're leaving dynamic acceleration off, you're paying for the CDN's network but using only a fraction of its power. Let's look at three techniques.

Technique 1: Connection Reuse — Free Latency Savings

Every time a user makes an HTTPS request to your origin, their browser must open a TCP connection and negotiate a TLS handshake with the origin server. From the user's location in, say, Tokyo to your origin in Virginia, that's 2–3 round trips × 160 ms each = 320–480 ms just in setup overhead before a byte of response travels.

A CDN solves this because it already has persistent, pre-warmed TCP+TLS connections to your origin. The CDN maintains a pool of keep-alive connections — often hundreds — between its edge nodes and your origin. When your Tokyo user makes a request, the edge terminates the user's connection locally (10 ms round trip) and multiplexes the request through an existing connection to origin. The TCP + TLS setup overhead to origin happens once and is amortized across thousands of requests. The user pays 10 ms (edge RTT) instead of 480 ms (origin RTT).

The diagram shows the contrast. Without CDN, every user request from Tokyo to Virginia pays the 480 ms TCP+TLS setup cost. With CDN, the user pays 10 ms to reach the Tokyo edge; the edge uses its pre-established connection pool to Virginia. This technique accelerates every dynamic request — even ones the CDN can't cache — because it eliminates the connection setup overhead on the user's side. It's a free win that many teams don't realize they're getting.

Technique 2: Short-TTL API Caching — Even 5 Seconds Matters

A common misconception: "Our API returns user-specific data, so we can't cache it." That's true for responses that contain session-specific content. But many API endpoints return the same data for all users (or for all users in a region): product listings, search results, trending posts, public pricing, weather data. These can be cached at the CDN edge with a short TTL.

The math here is counterintuitive. If your product listing endpoint handles 10,000 requests per second and you set a 5-second CDN TTL, the CDN serves at most 2 requests per edge node per 10 seconds to origin (one to fill, one potential revalidation). That's roughly 12 origin requests per hour per edge — instead of 36 million. A 5-second TTL reduces origin load by 99.997%. The data is at most 5 seconds stale — entirely acceptable for most product catalogs.

Technique 3: Edge-Side Includes (ESI) — Assembling Pages at the Edge

Sometimes a page is 95% public content (cacheable for hours) but has a small dynamic fragment — a shopping cart count, a logged-in username, a personalized recommendation block. Traditionally, the whole page would be marked Cache-Control: private and served from origin for every user, because of that small dynamic slice. ESI (Edge Side Includes) solves this by letting the CDN assemble the page at the edge from separately cached fragments.

ESI markup is simple: you mark sections of an HTML template with <esi:include src="..."> tags. When the CDN edge processes the response, it fetches and inserts the named fragments — some from local cache, some from origin. Akamai has supported ESI for decades; Varnish and Fastly have native ESI support. The practical impact: pages that were previously uncacheable because of a small dynamic slice become 90–99% cacheable, with only the dynamic fragment touching origin.

A CDN is security infrastructure whether you treat it that way or not. When you route all your traffic through a CDN's global network, you're also routing all attack traffic through it — and those 300+ globally distributed edge nodes are simultaneously your biggest defence and your most important security boundary. Understanding how CDNs handle DDoS, malicious requests, bots, and TLS makes the difference between "CDN as a performance tool" and "CDN as a security layer."

DDoS Mitigation — Volume Absorbed by Distribution

Imagine someone wants to take your website offline. The simplest way is to flood it with so many fake requests that real users can't get through — like a mob blocking the door of a coffee shop so paying customers can't enter. When that mob is made of thousands of hijacked computers all around the world hitting your server at once, that's called a DDoS (Distributed Denial of Service) attack. The fundamental defence a CDN provides is structural: there's no single server to overwhelm. Instead of your one origin handling all traffic, attack traffic is absorbed across hundreds of edge nodes worldwide.

Cloudflare has published publicly that in February 2023, they mitigated what they described as the largest HTTP DDoS attack on record at the time, peaking at 71 million requests per second — a genuine astronomical number, coming from over 30,000 IP addresses across numerous cloud providers (subsequent attacks have since surpassed this, including a 201M rps record set in August 2023 and multi-Tbps network-layer attacks in 2025). The key reason they could absorb it is Anycast routing: when traffic arrives destined for Cloudflare's IP addresses, BGP routes it to the nearest PoP. The attack was automatically distributed across hundreds of PoPs worldwide; no single location received an overwhelming fraction. A server at a startup's data center would have been unreachable in seconds. Cloudflare's edge barely noticed.

WAF — Web Application Firewall

Beyond raw flood absorption, a CDN can also act as a smart bouncer at the door — reading each incoming request and turning away the ones that look like attacks before they reach your application code. That smart-bouncer layer is called a WAF (Web Application Firewall). It sits at the CDN edge and inspects every incoming HTTP request for malicious patterns. When a request arrives, the WAF checks it against rule sets — some provided by the CDN vendor, some custom. Rules look for things like:

• SQL injection — query parameters like ?id=1' OR '1'='1 that attempt to manipulate backend database queries
• XSS (Cross-Site Scripting) — inputs containing <script> tags or JavaScript event handlers designed to execute in another user's browser
• Path traversal — requests like ../../../../etc/passwd trying to read files outside the web root
• Known CVE patterns — signatures for specific known vulnerabilities (e.g., Log4Shell, Spring4Shell)
• Rate limiting — a single IP making 1,000 requests per minute gets throttled or blocked

The critical advantage: the WAF runs at the CDN edge, before the request ever touches your origin. A SQL injection attempt is blocked in Tokyo, never reaching your database in Virginia. Cloudflare WAF, AWS WAF (bundled with CloudFront), Fastly's WAF, and Akamai Kona Site Defender all follow this pattern.

Bot Management

Not all automated traffic is malicious — search engine crawlers are bots you want. But credential stuffing bots, scrapers, scalper bots (buying limited-edition products), and ad fraud bots are expensive. CDN-based bot management distinguishes legitimate humans and good bots from malicious ones through a combination of:

• JavaScript fingerprinting — serving a JS challenge to suspicious clients; real browsers execute it, simple HTTP clients don't
• Behavioural analysis — humans move mouse, pause between clicks, navigate non-linearly; bots click in milliseconds with perfect precision
• Reputation scoring — known bot IP ranges, Tor exit nodes, hosting provider IP blocks known for abuse
• CAPTCHAs — as a last resort for ambiguous requests

TLS Termination at the Edge — and What Happens Behind It

When a user connects to your site over HTTPS, the TLS handshake terminates at the CDN edge, not at your origin. This means the user's encrypted session ends at the Tokyo edge node; the edge decrypts the request, inspects it (WAF, cache lookup), and either serves from cache or forwards to origin. The edge-to-origin connection is a separate TLS session — or, in some configurations, plain HTTP over a private network between the CDN and your origin. The user always has an encrypted connection; the internal CDN-to-origin path depends on your configuration.

Modern CDNs also support HTTP/3 + QUIC on the user-to-edge leg. QUIC is a UDP-based protocol designed to solve TCP's major latency problems — particularly the head-of-line blocking problem, where a lost packet stalls the entire stream. On mobile networks where packet loss is common, HTTP/3 can reduce perceived latency noticeably. Cloudflare, Fastly, and Akamai all support HTTP/3 at the edge; the edge-to-origin leg typically stays on HTTP/2 over TLS.

CDNs have some of the sneakiest failure modes in web infrastructure. Misconfiguring one header can silently reduce your cache hit ratio to zero. Getting one directive wrong can serve one user's session data to a completely different user — a GDPR-violating catastrophe. These are the seven most common production mistakes, each documented from real incident patterns.

CDN knowledge only becomes intuition through practice. These five exercises are designed to move you from "I read about it" to "I can reason about it from first principles." Work through each one before expanding the solution — the struggle is where the learning happens.

Theory is one thing. Production incidents are another. The four bugs below are drawn from real patterns that teams have hit: a session leak that exposed user A's data to user B, a Vary header that shattered cache efficiency, an accidental error caching that took a site offline globally for an hour, and a deploy-triggered thundering herd that killed the origin. Each one is an easy mistake to make — and each one is completely preventable once you know the pattern.

CDN products look similar from the outside — you CNAME your domain to their nameservers and traffic starts being served from the edge. But under the hood, five different companies made radically different architectural bets. Netflix built their own hardware and shipped it to ISPs. Cloudflare bet on Anycast and software-defined everything. Akamai's hierarchical design predates most of the other players. CloudFront leverages AWS's existing infrastructure. Fastly bet on instant purge as a competitive differentiator. Understanding these architectures tells you why each CDN is the right answer for different use cases.

These are the beliefs that feel correct but aren't — the ones that cause real production mistakes. Each one is a mental model that seemed reasonable until someone tested it in production. Read each correction before it costs you a P1 incident.

Picking a CDN is the easy part. The hard part is onboarding it correctly, configuring it so it actually improves performance rather than adding a mysterious failure point, and tuning it over time as your traffic patterns evolve. This playbook walks through five stages of a production CDN deployment.

The five stages are a loop, not a one-time checklist. Traffic patterns change, costs evolve, and what worked at 10,000 daily users may need rethinking at 10 million. Let's walk through each stage.

A quick-reference grid of the core CDN concepts, followed by a glossary of every term you'll encounter in CDN documentation, job descriptions, and incident reports.

Quick-Reference Cheat Sheet

Glossary

PoP

Point of Presence — a CDN data center or co-location facility in a specific city where edge nodes are housed.

Anycast

A routing strategy where one IP address is advertised from many physical locations via BGP. Packets are delivered to the topologically nearest node, not a specific machine.

GeoDNS

DNS that returns different IP addresses depending on the geographic location of the querying resolver. Different from Anycast — routing happens in DNS, not in the network layer.

BGP

Border Gateway Protocol — the routing protocol that determines paths between autonomous systems on the internet. Anycast CDNs use BGP to announce their IP from many locations simultaneously.

edge compute

Running application code (JavaScript, WASM, Rust) on CDN edge nodes rather than on the origin server. Examples: Cloudflare Workers, Lambda@Edge, Fastly Compute@Edge.

ESI

Edge Side Includes — an XML-based templating language processed at the CDN edge to compose pages from separately-cached or dynamically-fetched fragments.

surrogate key

A tag added to cached responses (via Surrogate-Key or Cache-Tag header) enabling group invalidation — one API call can purge all objects sharing a tag. Pioneered by Fastly, now supported by most enterprise CDNs.

Vary header

An HTTP response header listing which request headers were used to select the response. The CDN creates separate cache shards for each unique combination of the listed header values. Dangerous with high-cardinality headers like User-Agent.

conditional GET

A GET request with an If-None-Match (ETag-based) or If-Modified-Since header. The origin returns 304 Not Modified if the resource hasn't changed, saving transfer bandwidth while confirming freshness.

byte-range request

An HTTP request for a specific byte range of a resource (Range: bytes=0-1048575). Used by video players to fetch HLS/DASH chunks; CDNs must handle these correctly and can serve them from a cached full response.

origin shield

A centralized intermediate caching layer between CDN edge nodes and the origin server. All cache misses from all edges funnel through origin shield first, collapsing a distributed miss storm into a single origin fetch.

tiered caching

A CDN topology with multiple cache layers (edge → regional parent → origin shield → origin). A miss at the edge is filled from the regional parent rather than the origin, reducing origin load and inter-region bandwidth costs.

cold start

The latency penalty incurred when an edge compute function (Cloudflare Worker, Lambda@Edge) needs to initialize a new execution context because no warm context is available. V8 isolate cold starts are sub-ms; Lambda@Edge Node.js cold starts can be 100-500 ms.

HTTP/3

The third major HTTP version, using QUIC (a UDP-based transport) instead of TCP. Key advantages: 0-RTT reconnection for returning clients, no transport-layer head-of-line blocking across multiplexed streams.

QUIC

Quick UDP Internet Connections — a transport protocol developed by Google, now standardized as RFC 9000. Implements reliable delivery, flow control, and congestion control over UDP rather than TCP. The foundation of HTTP/3.

CDNs sit at the intersection of several large topic areas. Each card below explains why the topic is worth studying next and how it connects to what you just learned about CDNs.