Why this matters
The speed of light is not a suggestion — it's a hard limit. A user in Sydney requesting a file from a server in Virginia waits roughly 200 milliseconds just for the round trip, before your server does a single useful thing. No amount of code optimization fixes physics. A CDN (Content Delivery Network) fixes it the only way physics allows: by moving the content closer to the user. Netflix, YouTube, and every fast website you've ever used lean on this trick.
Picture a popular restaurant chain. The flagship kitchen in one city makes an incredible sauce — but shipping every serving across the country would be slow and expensive. So the chain opens regional kitchens that keep the sauce ready to go. Diners everywhere get the same dish, fast. A CDN is a network of regional kitchens for your bytes: hundreds of edge locations (Points of Presence, or PoPs) that cache your content near your users.
Video: What is a CDN? - #Cloudbits Episode 2 — Cloudflare Developers
Opens with the distance problem, then shows how CDNs cut latency, absorb traffic spikes, and shield origins.
The request path
flowchart LR
U[User in Sydney] --> E[Edge PoP<br/>Sydney]
E -->|Cache HIT| U2[Response in ~10ms]
E -->|Cache MISS| O[Origin server<br/>Virginia]
O --> E2[Fill edge cache]
E2 --> U3[Response in ~200ms<br/>next user gets 10ms]
The first user in a region pays the full round trip; everyone after them gets the cached copy. The metric that runs the whole business is the cache hit ratio: the fraction of requests served from the edge without touching your origin. Static assets (images, video, JS bundles) routinely hit 95%+; personalized API responses might be near 0%.
Interactive diagram: VsToggle (loads in the app)
Interactive diagram: CdnFlow (loads in the app)
Video: What is a CDN? — ByteByteGo
ByteByteGo traces a request from your browser to the nearest edge cache — like grabbing a book from your local library branch instead of the national warehouse.
The cache hierarchy
Large CDNs don't have just one layer. A typical setup:
flowchart TD
U[User] --> E[Edge PoP<br/>~hundreds worldwide]
E -->|miss| R[Regional cache<br/>~dozens worldwide]
R -->|miss| S[Origin shield<br/>single layer in front of origin]
S -->|miss| O[Your origin server]
Each layer shields the one below it. The origin shield is the unsung hero: a single caching layer that collapses duplicate misses from many edges into one request to your origin. Without it, a cache flush across 300 edges means 300 simultaneous requests to your origin — the thundering herd's globe-trotting cousin (see Caching Strategies).
Video: What is a CDN (Content Delivery Network)? — InterviewReady (Gaurav Sen)
InterviewReady shows why one central cache buckles and how geo-distributed edges take over — like swapping a single giant warehouse for stocked corner stores everywhere.
TTLs, purging, and versioning
Everything cached at the edge eventually goes stale, and CDNs manage that with the same tools you already know: TTLs and purging. Purge ("invalidate this URL everywhere, now") sounds perfect until you learn it can take seconds to minutes to propagate to every PoP — during a security incident, those seconds feel very long.
The industry's favorite dodge is content versioning: never change a file in place;
instead, ship app.v2.js alongside app.v1.js and update the reference. Immutable assets
get year-long TTLs and never need purging. Your HTML (short TTL, or uncached) points at the
new filenames. Stop mutating files in place and a whole class of staleness bugs simply
disappears.
Video: CDNs Explained — How Content Delivery Networks Make Websites Faster — NetWorks
Cache TTL, invalidation and purge, plus versioned and hashed files — the three freshness levers, and how edge PoPs route you to the nearest copy.
Dynamic content acceleration
"What about content that can't be cached — personalized pages, API responses?" CDNs still help, through the boring magic of better networking:
- Persistent, warm connections between edge and origin (no TCP/TLS handshake per request).
- Smarter routing — the CDN's private backbone often beats the public internet's meandering path. (Your packets take the highway; everyone else takes side streets.)
- TLS termination at the edge — the expensive handshake happens close to the user.
Cloudflare, CloudFront, Fastly, and Akamai all sell this. Nobody will ever thank you for the 80 milliseconds you shaved off their API call, but the conversion-rate graphs will.
Video: Content Delivery Network (CDN) Basics by CDNetworks — Web Acceleration Channel - by CDNetworks
CDNetworks engineers walk through the techniques used to accelerate dynamic, non-cacheable content across the network.
Picking and configuring
A few practical trade-offs worth knowing:
- Pull vs. push: in pull (origin pull) the CDN fetches from your origin on miss — simplest, and what most sites use. In push, you upload content to the CDN's storage directly — better for huge files (video libraries) where you don't want origins involved.
- Anycast routing: your domain resolves to one IP advertised from every PoP; BGP routing sends each user to the nearest one. This is why one DNS answer serves the planet.
- Cost model: you pay mostly for egress bandwidth and requests. A misconfigured cache (low hit ratio) doesn't just hurt latency — it shows up on the invoice, twice.
Video: How to implement a CDN — Contabo
Walks through choosing a provider, pointing DNS at it, and tuning Cloudflare caching, compression, and SSL settings.
Takeaways
- CDNs beat the speed of light by moving content to edge PoPs near users; the cache hit ratio is the metric that matters.
- Layer the caches — edge, regional, origin shield — so misses don't stampede your origin.
- Version static assets immutably instead of purging; purge is slower and scarier than it looks.
- Even uncacheable dynamic content gets faster through warm connections and better routing.
Check your understanding
What is a CDN's primary answer to the latency imposed by the speed of light?
- Compressing content more aggressively
- Moving cached copies of content to edge PoPs near users
- Upgrading the origin server's CPU
- Reducing the number of HTTP requests per page
What does an 'origin shield' do?
- Collapses duplicate cache misses from many edges into a single request to the origin
- Automatically scales the origin server up and down
- Blocks DDoS attacks at the network edge
- Encrypts traffic between the user and the edge
Why do teams version static assets (app.v2.js) instead of overwriting app.js?
- Versioned files compress better
- CDNs refuse to cache files without version numbers
- Browsers require version numbers to parse JavaScript
- Immutable versioned files can use very long TTLs and never need purging
How does a CDN speed up dynamic, uncacheable content?
- It cannot help at all with dynamic content
- By converting dynamic pages into static HTML
- Through warm persistent connections, smarter routing, and TLS termination at the edge
- By caching it anyway and hoping nobody notices
Go deeper
Want to keep pulling this thread? These talks and tutorials go further than we did here:
- Content Delivery Networks (CDN) in Cloud Systems Design — SystemsArchitect.io, YouTube tutorial. PoPs, anycast, cache keys, purge, and origin shields.
- What Is A CDN? How Does It Work? — ByteByteGo. Multi-tier caching, purge APIs, request coalescing, and recovery.
- Why Distance Doesn't Matter (CDNs) — Neural Download (~7 min). A fast primer: PoPs, hits and misses, invalidation, DNS routing.
- System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra — freeCodeCamp.org (~2h 05m). Dedicated CDN coverage inside a full system-design course.
- System Design for Beginners Course — freeCodeCamp.org, taught by Gaurav Sen (~1h 25m). Watch the CDN chapter (~0:41:55) — CDNs inside a real live-streaming pipeline.
Sources & further reading
- Cloudflare Learning Center, "What is a CDN?" and "How CDN caching works" — the clearest vendor-neutral explainer set.
- AWS documentation, "Amazon CloudFront" — origin shields, cache behaviors, invalidation.
- Fastly engineering blog — edge computing and purging at scale (notably "Instant Purge" internals).
- Erik Nygren, Ramesh K. Sitaraman & Jennifer Sun, "The Akamai Network: A Platform for High-Performance Internet Applications," ACM SIGOPS Operating Systems Review, 2010 — the academic view of CDN architecture.