CDNs: Caching at the Edge of the World
A Content Delivery Network is a fleet of servers spread across the globe that cache your content close to your users. Instead of every request traveling thousands of miles to a single origin, it is answered by the nearest edge — in milliseconds. A CDN is, at heart, a cache: the same hit/miss idea you already know, but distributed geographically so distance stops being the bottleneck.
Why Distance Is the Enemy
Networks are fast, but the speed of light is finite. A request from Sydney to a server in Virginia crosses the planet and back — a round-trip that costs hundreds of milliseconds no matter how quick your backend is. A CDN (Content Delivery Network) fixes this by placing copies of your content in PoPs (Points of Presence) — edge locations in hundreds of cities — so users are served by a machine a few miles away instead of a continent away.
Without a CDN (every user hits the origin)
User in Tokyo ──── 260ms ────► Origin in Virginia User in Berlin ──── 180ms ────► Origin in Virginia User in Dallas ──── 90ms ────► Origin in Virginia Every byte crosses the ocean. The origin serves the whole planet alone — and buckles under a traffic spike.
With a CDN (nearest edge answers)
User in Tokyo ──► Tokyo edge (20ms) cache HIT User in Berlin ──► Frankfurt edge (22ms) cache HIT User in Dallas ──► Dallas edge (18ms) cache HIT Only cache MISSES travel to the origin — and once fetched, the edge keeps the copy for everyone nearby.
It's the Caching Idea, Spread Out
If you've read the caching page, a CDN will feel familiar: it's a read-through cache with hits and misses. The twist is where the cache lives — not next to your database, but in hundreds of cities next to your users. Latency drops because of proximity, and the origin is shielded because most reads never reach it.
What a CDN Actually Buys You
A CDN is more than a speed trick. It changes the shape of your traffic and your risk profile.
Lower latency
Content is served from the edge nearest the user, cutting a cross-continent round-trip down to a local hop.
Origin offload
Most requests are answered by edges, so the origin sees a small fraction of total traffic. You can run a smaller, cheaper backend.
Absorbing spikes and attacks
A viral moment or a DDoS flood hits the CDN's enormous distributed capacity first, not your single origin. Many CDNs bundle DDoS mitigation and WAF features.
Bandwidth savings
Serving cached bytes from the edge is cheaper than serving them from your origin's egress, and it reduces load on your network.
Routing and the Hit / Miss Path
Two things have to happen: the request must reach the nearest edge, and that edge must decide whether it can answer from cache.
Getting to the nearest edge
CDNs steer users to a close PoP using DNS-based routing (the CDN's DNS returns the IP of a nearby edge based on the resolver's location) or anycast (many edges announce the same IP, and the network naturally delivers packets to the closest one). Either way, the user's browser ends up talking to a server a short distance away.
Hit vs miss at the edge
Request arrives at nearest edge
├─ cache HIT → serve the cached copy immediately (~20ms)
└─ cache MISS → fetch from origin (~250ms)
store the copy at the edge
serve it, and every later request nearby is a HITPush vs Pull CDNs
A pull CDN is lazy: the edge fetches content from the origin the first time it's requested, then caches it. Simple and the default for most sites. A push CDN is eager: you upload assets to the CDN ahead of time, so they're in place before any user asks. Push suits large, infrequently changing files (video, big downloads) where you'd rather not pay a miss on first request.
What to Cache, and for How Long
The origin tells the CDN what is cacheable using HTTP headers. Get these right and the CDN does the rest.
Static content — cache aggressively
Images, CSS, JS bundles, fonts, video. These rarely change and are identical for every user, so give them long TTLs.
Dynamic content — cache carefully or not at all
Personalized pages, authenticated API responses, anything with a per-user cookie. Cache these only with short TTLs or explicit rules, or you'll serve one user's data to another.
TTL and Cache-Control
The TTL (time to live) is how long an edge may serve a copy before revalidating with the origin. It's driven by response headers.
Cache-Control: public, max-age=31536000, immutable → cache for a year, never revalidate (great for versioned assets) Cache-Control: public, max-age=60, stale-while-revalidate=30 → serve for 60s, then keep serving stale for 30s while refreshing Cache-Control: private, no-store → never cache (per-user or sensitive responses)
Invalidation and Purging
When content changes before its TTL expires, you either purge it (tell the CDN to drop the cached copy) or, better, use versioned URLs so the new content has a new address entirely. Purging is slower and can miss edges; cache-busting via filenames like app.7f3a1c.js is instant and reliable because a new URL is simply an unconditional miss.
Edge Compute: Logic at the PoP
Modern CDNs don't just cache bytes — they run code. With edge functions (Cloudflare Workers, Lambda@Edge, Fastly Compute), you execute small pieces of logic at the PoP, close to the user.
This lets you do request routing, A/B splits, auth checks, header rewrites, geolocation, and even assemble personalized responses — all without a round-trip to a distant origin. The edge becomes a thin, globally distributed compute layer that sits in front of your backend.
Live Edge Latency Simulation
CDN Pitfalls
- →Caching things you shouldn't: put a per-user or authenticated response in a shared edge cache and you'll leak one user's data to the next. Mark private/dynamic content no-store.
- →Stale content after a deploy: users keep getting old assets because the old TTL hasn't expired. Version your asset URLs so a deploy is automatically a cache miss.
- →Relying on purge for freshness: purges propagate slowly and can miss edges. Cache-busting via versioned filenames is instant and reliable — prefer it.
- →Forgetting the Vary header: caching a response without varying on things like Accept-Encoding or Authorization serves the wrong variant to some users.
- →Ignoring cost: egress and per-request fees add up, and a low hit ratio means you pay for the CDN and still hammer the origin. Watch your hit rate.
- →Treating a CDN as a database: it caches content near users, it does not make your origin, writes, or dynamic queries magically fast.
Key Takeaways
- →A CDN is edge caching: geographically distributed PoPs cache content close to users so distance stops being the bottleneck.
- →It cuts latency via proximity, offloads the origin, absorbs traffic spikes and DDoS, and saves bandwidth.
- →Users reach the nearest edge via DNS-based routing or anycast; a hit is served instantly, a miss fetches from origin and then populates the edge.
- →Pull CDNs fetch on first request (the common default); push CDNs are preloaded, good for large static files.
- →Cache static content aggressively with long TTLs; be cautious with dynamic or per-user content. Cache-Control headers drive TTL.
- →Invalidate with versioned URLs for instant, reliable cache-busting; use purges sparingly.
- →Edge functions let you run logic at the PoP — routing, auth, personalization — without a trip to the origin.
Quick Reference: Major CDNs
Cloudflare
Huge anycast network, generous free tier, strong DDoS/WAF, and Workers for edge compute. A common default for the whole web.
Akamai
The oldest and one of the largest CDNs, with an enormous PoP footprint. Favored by big enterprises and media delivery.
Fastly
Known for instant purges and fine-grained control via VCL, plus Compute@Edge. Popular where dynamic content and fast invalidation matter.
Amazon CloudFront
AWS's CDN, tightly integrated with S3, ALB, and Lambda@Edge. The natural choice when your stack already lives in AWS.
Good for / not for
Great for static assets, media, and cacheable API responses served globally. Not a fix for slow origins, heavy write paths, or highly personalized data that can't be cached.