What a CDN Really Does — and Why Nearly Every Site Uses One

A content delivery network is a rented copy of your website, kept in a few hundred cities so that nobody has to talk to your server. That single idea — move the bytes closer, and answer most requests before they reach the origin — is why CDNs now sit in front of a large share of the web, and why a bad configuration push at one company can take a visible slice of the internet offline for an afternoon.

Origin, edge, and the request that never happens

Your origin is the server that actually holds the site: the application, the database, the files. An edge server is a machine in a CDN’s point of presence — a PoP, typically a rack or two inside a carrier-neutral data centre — that holds a copy of whatever it has recently been asked for.

When a browser requests an image, the edge either has it (a cache hit, answered in a few milliseconds from local storage) or it does not (a cache miss, which means fetching from the origin and storing the result on the way back). The whole business model is the ratio between the two.

Getting the request to a nearby PoP is done with anycast: the same IP address is announced by BGP from every PoP at once, and each network’s routing simply delivers packets to whichever announcement looks closest to it. There is no clever geolocation database in the path. The routing table does the work, which is why anycast is both very fast and slightly unpredictable — “closest” means closest in BGP terms, not in kilometres.

Cache hit ratio is the number that matters

Cache hit ratio is hits divided by hits plus misses. Cloudflare’s learning centre notes that a mostly-static site can sit comfortably in the 95–99% range, while a site heavy with personalised responses will do far worse — and that maximising the ratio is not the only goal, since serving a stale wrong answer quickly is not a win.

What the edge is allowed to store is decided by HTTP response headers, standardised in RFC 9111, published in June 2022 as part of the revised HTTP specification suite. The directives worth knowing:

• max-age — seconds before the response is stale, for any cache.
• s-maxage — the same, but only for shared caches such as a CDN. It overrides max-age, which lets you cache aggressively at the edge and barely at all in the browser.
• private — a shared cache must not store this. The correct header for anything containing one user’s data.
• no-store — nobody stores it, anywhere.
• no-cache — confusingly, this permits storage but requires revalidation with the origin before reuse.

The most common real-world failure is a site that caches almost nothing because a framework emits private or no-store by default, and the second most common is a site that caches a logged-in page because someone set public without thinking. Cache key design matters too: if the cache key includes every query string, a marketing campaign appending tracking parameters will fragment one popular page into thousands of separate objects, each with its own miss.

Purging

Because edge copies have their own lifetimes, publishing a correction does not automatically remove the old version. CDNs offer purge — by URL, by tag or surrogate key, or the whole zone — and the discipline is to purge by tag on publish rather than to set short TTLs everywhere. Short TTLs turn every edge into a proxy that constantly re-asks your origin, which is precisely the load a CDN exists to remove.

TLS ends at the edge

For an HTTPS site behind a CDN, the encrypted connection terminates on the edge server, not on your origin. The edge holds a certificate for your hostname, completes the handshake, and opens a separate connection back to the origin.

This is a genuine performance win, because a handshake costs round trips and round trips cost distance. Terminating 20 ms away instead of 120 ms away saves that difference several times over during connection setup, before a single byte of content moves. It also lets the CDN run modern TLS and HTTP versions on the public side regardless of what your origin supports.

It is also a real trust decision: the CDN sees your traffic in plaintext. That is not a scandal — it is the architecture — but it belongs in your threat model, and it is the reason regulated workloads sometimes keep origin-side encryption and accept the latency.

Why a CDN absorbs denial-of-service traffic

Anycast is what makes CDNs accidental DDoS filters. A botnet firing at your anycast address does not concentrate on one machine; each attacking host’s packets go to whichever PoP its own network routes to. Cloudflare’s write-up of a 7.3 Tbps attack in mid-May 2025 describes exactly this: the flood, which delivered 37.4 terabytes in 45 seconds, was spread across 477 data centres in 293 locations and mitigated close to the sources.

The scale has moved fast. Cloudflare’s Q4 2025 DDoS report puts the year’s largest attack at 31.4 Tbps, lasting 35 seconds, out of 47.1 million attacks mitigated across 2025. No single origin server absorbs that. A distributed network with hundreds of terabits of aggregate capacity does, because the attack arrives pre-divided.

The concentration problem

The 2025 edition of the HTTP Archive’s Web Almanac, published in January 2026, found that 35% of mobile HTML and 71% of third-party requests were served through a CDN, with Cloudflare accounting for 58% of CDN-served HTML and Google 53% of CDN-served third-party requests. Resilience bought by moving to a shared network is resilience shared with everyone else on it.

Four confirmed incidents show what that costs.

Date	Provider	Cause	Impact window
2 July 2019	Cloudflare	A WAF rule containing a regular expression that backtracked catastrophically, pushing CPU to nearly 100% network-wide	Deployed 13:42 UTC, traffic normal 14:09 — about 27 minutes of 502s
8 June 2021	Fastly	A bug shipped on 12 May, latent until a valid customer configuration change triggered it	Began 09:47 UTC, detected within a minute, 95% of the network normal within 49 minutes, fully mitigated 12:35
22 July 2021	Akamai	A software configuration update triggered a bug in the DNS system of its secure edge CDN	From 15:45 UTC, up to one hour, resolved by rollback
18 November 2025	Cloudflare	A database permissions change made a query return duplicate rows, doubling a Bot Management feature file past a 200-feature preallocation and panicking the proxy	Errors from 11:28 UTC, main impact resolved 14:30, all services restored 17:06

Read the pattern rather than the vendors. None of these was an attack, a data centre fire or a cut cable. Every one was a configuration or code change propagating globally in minutes, which is the same property that makes a CDN useful. Fastly’s post-mortem is candid that the triggering customer change was entirely valid; Cloudflare’s November 2025 write-up traces a five-and-a-half-hour incident to a permissions change on a database.

The practical version

• Measure your cache hit ratio before optimising anything else. If it is below 80% on a mostly-static site, the problem is your headers, not your provider.
• Use s-maxage for the edge and a shorter max-age for browsers, and purge by tag on publish instead of setting everything to 60 seconds.
• Audit which responses carry private. Anything with a session in it should, and anything without one probably should not.
• Know your origin’s failure mode. Can it survive its own traffic with the CDN bypassed? During a CDN outage that is exactly the test you get.
• Keep DNS TTLs low enough to fail over and keep a documented, rehearsed path to your origin. Multi-CDN is real insurance but it is not cheap; a bypass runbook costs an afternoon.
• Do not assume the edge is neutral infrastructure. It terminates your TLS, sees your traffic and ships config globally in minutes. That is the deal.