CDNs serve your content from close to the user.
A network of strategically placed caches answering on behalf of your origin. The work is half routing trick, half cache, and half operational hygiene. Together they cut p99 latency by an order of magnitude. The same hierarchy idea operates at every scale — see the memory hierarchy for the eight orders of magnitude inside one CPU.
What is a CDN?
One IP, three hundred locations.
A CDN (Content Delivery Network) is a global network of caching servers (PoPs — Points of Presence) that sit between users and the origin server, serving cached content from the nearest PoP. Akamai pioneered the model in 1998; today Cloudflare, Fastly, AWS CloudFront, Google Cloud CDN, and Akamai operate hundreds of PoPs each. Anycast routing, origin shielding, edge functions, and DDoS mitigation are all standard.
A CDN is a fleet of Points of Presence — small datacenters scattered close to users — all answering on the same IP address. Anycast is what makes that work: every PoP announces the same prefix into BGP, and the internet routes packets to the topologically nearest one. A user in Sydney and a user in Stockholm both type the same hostname, get the same IP, and end up on completely different machines a few milliseconds away.
See the DNS guide for how authoritative resolution often pre-selects the nearest PoP's IP, and the BGP guide for how anycast routing actually works at the protocol level.
Watch anycast route a user to the nearest PoP
Move the user and toggle a PoP between hot and cold.
Click anywhere on the map to move the user. Anycast routes to the nearest PoP. Toggle a PoP's cache state to see what happens on a cold edge — the request walks back to origin, costs more, populates the cache, and the next request from that region is fast.
The cache key: what makes two requests the same
Host, path, query, and Vary all factor in.
A cache hit happens when the cache key matches a previously-stored response. The default key is the request URL, but every CDN lets you tune it — and tuning it wrong is one of the most common causes of "why is hit rate so bad."
- host + path
Host and path are the base key
example.com/style.css is the canonical key. Different host, different cache. Different path, different cache. Lowest-common denominator across CDNs.
- + query
Query strings make separate entries
By default, query strings make different keys — ?v=1 and ?v=2 are separate cache entries. For tracking parameters (utm_*, fbclid), you want them ignored — otherwise every campaign URL is a fresh miss.
- + Vary
Vary splits the cache per client
Vary: Accept-Encoding means "different responses for different clients depending on whether they accept Brotli/gzip/raw." The CDN stores a separate variant per encoding. Vary: Cookie essentially defeats caching — unique cookie per user means unique key per user.
Origin shielding: one PoP fetches for the rest
The origin sees one fetch instead of dozens.
With dozens of PoPs and a 24-hour TTL, the origin still gets hit once per object per PoP per day. For very popular content this is unnecessary load. Origin shielding designates one PoP as the only one allowed to fetch from origin — every other PoP that misses must consult the shield first. The origin sees one fetch instead of dozens.
Used universally by image hosts and software distribution networks. The downside is one extra hop on cold-shield misses. The upside is that origin can be a tiny infrequently-stressed machine instead of a hardened tier sized for direct global traffic.
Edge functions: running code at every PoP
Workers and Lambda@Edge, in a few milliseconds.
Modern CDNs let you run code at every PoP. Cloudflare Workers, Fastly Compute, CloudFront Functions, Vercel Edge — each runs a request-scoped script in a sandbox (V8 isolate, WebAssembly) that can read and modify the request before it hits the cache, and the response before it goes back. Authentication, A/B routing, geo redirects, header rewriting, signed-URL validation — all in 1–5 milliseconds at the edge.
The contract is sharp: tiny memory budgets (typically a few MB), short execution time (low tens of milliseconds), no persistent disk. What you can do at the edge is what fits in that envelope. Anything heavier — long-running queries, complex business logic — still belongs at origin.
Purging content before its TTL expires
Single URL, surrogate key, or the whole cache.
When content changes, the CDN copies are wrong until their TTL expires. For most content the natural decay is fine. For breaking news, hot fixes, or product launches, you push a purge — explicit invalidation across the network.
Purge one specific URL
Purge one cache key. Fast (single-digit seconds across global PoPs on modern CDNs), cheap, the most common operation. Point solution.
Purge everything with a tag
Tag responses with a Surrogate-Key: product-1234 header at origin; later, purge by tag. Lets you invalidate every page that mentioned a product in one call. Fastly's killer feature; available on others.
Purge the entire cache
Wipe the entire cache for a property. Used in genuine emergencies — leaked credential in a public response, GDPR compliance, broken cache key. Costs the next hour as cold misses warm everything back up. Don't reach for this casually.
Security at the edge: DDoS, WAF, and bots
The perimeter in front of your origin.
The CDN sits between the public internet and your origin, which makes it a natural place to put defensive logic. Modern CDNs ship a stack of security capabilities that you would otherwise build piecemeal:
- DDoS
- WAF
Web Application Firewall
Pattern-match against OWASP Top 10 attempts (SQLi, XSS, RCE) before they reach origin. Managed rule sets stay current; custom rules let you block exact patterns you've seen.
- bot management
Distinguish humans, bots, scrapers
Behavioural fingerprinting plus IP reputation. Lets the good bots through (search engines, monitoring), challenges the suspicious ones, blocks the known-bad. Hard to do well outside a network with global signal.
- TLS termination
Modern crypto, free
The CDN terminates TLS at the edge — TLS 1.3, OCSP stapling, ECDHE, modern cipher suites. Origin can speak older HTTP behind it. Free certificates via Let's Encrypt are the default; the CDN handles renewal.
How to choose a CDN
Footprint and edge runtime are what differ.
The big four — Cloudflare, Akamai, Fastly, AWS CloudFront — overlap heavily. The distinguishing axes that matter for most teams:
Where their PoPs are.
Akamai and Cloudflare have the largest. Where you serve users matters; if it's Vietnam and Brazil, the difference is real. Latency map dashboards on each provider tell the truth.
What you can run there.
Cloudflare Workers and Fastly Compute are the most capable; AWS Lambda@Edge is more constrained but tightly integrated with the rest of AWS. Pick by what code actually wants to live at the edge.
Already on AWS for everything else? CloudFront integrates flawlessly. Already on Cloudflare's DNS? Cache + Workers slot in trivially. The right CDN is usually the one that joins your existing stack with the fewest seams.
The five CDNs that serve most of the web
The five that serve most of the web.
- Cloudflare
- ~330 PoPs, free tier with generous limits, anycast across all edges. Workers (V8 isolates) for edge compute. Built-in DDoS protection, WAF, bot management. Strong on security tooling. Powers ~20% of the top 1M websites.
- Fastly
- ~70 PoPs, premium pricing, Varnish-based edge. Best instant-purge in the industry (~150ms global). Used by The New York Times, Stripe, Shopify. Compute@Edge runs WebAssembly. The CDN of choice for tech-forward shops.
- Akamai
- ~4,000 PoPs (the largest footprint). Enterprise-grade, premium pricing. The original CDN (1998) and the choice for Fortune 500 web properties, video streaming, and high-uptime workloads.
- AWS CloudFront
- ~600 PoPs. Tightly integrated with the rest of AWS (Lambda@Edge, S3 origin, Shield DDoS protection). Best fit if you're already on AWS. CloudFront Functions for tiny edge transforms; Lambda@Edge for heavier work.
- Google Cloud CDN
- Tightly coupled to Google Cloud Load Balancer; rides the Google network from edge to origin. Smaller market share but high-quality network performance, good fit if you're on GCP.
- Bunny.net / KeyCDN
- Smaller players with simpler pricing models. Bunny.net in particular is popular among smaller content shops; ~120 PoPs at fractional prices.
Multi-CDN. Large content shops (Netflix, Hulu, Spotify) run multi-CDN with traffic shaping based on real-time performance. The DNS-based traffic-direction layer (NS1, Cedexis, internal) shifts users to the best-performing CDN per region. Adds complexity; pays off at scale where any single CDN's regional outage would matter.
A CDN is a cache plus a security perimeter plus an edge runtime, distributed across hundreds of small machines close to users. The mechanics are old (anycast since the 1990s, HTTP cache since 2.0) — what changed is putting them all together in one coherent product. If your origin is at all popular and serves any non-personalized content, you are leaving an order of magnitude of latency on the table by not using one.
Further reading on CDNs
- CloudflareAnycast and traffic routingHow an anycast network actually picks PoPs in practice — including the cases where shortest-AS-path beats geographic proximity.
- FastlyWhat is a CDN?An operator-perspective overview from one of the more developer-focused providers. Solid on cache keys and surrogate-key purging.
- Semicolony guideDNS, how names resolveAuthoritative DNS often pre-selects the nearest PoP via geo-DNS or anycast — the layer underneath this guide.
- Semicolony guideBGP, the glueAnycast lives at the BGP layer. Read this if Part 01's "the internet routes packets to the nearest PoP" needs more grounding.
- Semicolony guideHTTP cachingThe cache layer that the CDN tier is one instance of — same primitives, applied at the edge instead of the browser.
- Semicolony guideLoad balancingGSLB — global server load balancing — is the routing layer that picks regions; the CDN is what runs at each region.