What is a CDN (Content Delivery Network)?
How the internet puts copies of your data closer to whoever's asking for it
TL;DR | An Analogy
A CDN is a globally distributed network of caches — like stocking every neighbourhood convenience store with your most popular items so nobody drives to the central warehouse. Users get the nearest copy; your origin server stays quiet.
The idea
A CDN is a layer of geographically distributed proxy servers (called edge nodes or Points of Presence, PoPs) that cache and serve content on behalf of an origin server. When a user requests a resource, DNS routes them to the nearest PoP. If the PoP has a fresh cached copy it serves it immediately — a cache hit. If not, it fetches from origin, caches it, then serves it. Result: lower latency, less origin load, and built-in redundancy.
Where it shows up
System design interviews: CDNs appear in almost every large-scale design — video platforms, e-commerce storefronts. Interviewers expect you to distinguish static caching (images, JS bundles) from dynamic acceleration (route optimisation, TLS termination at the edge). Name the tradeoff explicitly: stale cache vs. origin load.
On-call / incidents: A misconfigured Cache-Control header can cause a CDN to cache a 302 redirect, a 500 error page, or a user-specific API response and serve it globally for hours. Knowing how to issue a cache purge (and its cost/delay) is a real operational skill.
Real systems: Cloudflare, Fastly, and AWS CloudFront serve the majority of web traffic. If you work on any public-facing service — frontend assets, video streaming, API responses, software update packages — you are almost certainly already behind one.
Read the detailed breakdown›
How a request actually travels
When your browser resolves cdn.example.com, the CDN provider's authoritative DNS server responds with the IP of the nearest PoP — nearest usually means lowest RTT, determined by Anycast routing or GeoDNS. Anycast assigns the same IP prefix to multiple PoPs; BGP routing has a high probability to deliver your packet to the topologically closest one.
At the PoP, a reverse-proxy process (nginx, Varnish, or a proprietary equivalent) checks its local cache. Cache keys are constructed from the URL and, optionally, headers like Accept-Encoding or Accept-Language. On a cache hit, the response goes back directly — typical latencies are single-digit milliseconds. On a cache miss, the PoP opens a persistent, usually already-warm TCP/TLS connection to the origin, fetches the object, writes it to local storage (often a tiered memory + SSD store), and returns it.
Cache lifetime and freshness
The CDN respects HTTP caching semantics. Cache-Control: max-age=86400, s-maxage=3600 tells shared caches (CDNs) to cache for one hour and browsers for one day. Surrogate-Control (Fastly, Varnish) or CDN-Cache-Control (Cloudflare) let you set edge TTLs independently of browser TTLs — useful for serving fresh content to browsers while keeping CDN caches warm longer.
Conditional requests (If-None-Match, ETag, Last-Modified) allow a PoP to revalidate a stale object with a lightweight 304 Not Modified rather than re-fetching the full body.
Cache invalidation
This is the hard part. You have three mechanisms:
- TTL expiry — wait for max-age to elapse. Simple, but content is stale until then.
- Purge / instant invalidation — send an API call to the CDN to evict specific URLs or tags. Cloudflare's cache purge typically propagates globally in under a second. Fastly's surrogate key purging lets you tag thousands of objects and evict them with one API call.
- Cache-busting via versioned URLs — embed a content hash in the filename (
app.a3f9bc.js). The old URL remains in cache but is never requested again. This is the safest strategy for immutable assets.
Static vs dynamic content
Static: Images, fonts, JS/CSS bundles, video segments. These are the canonical CDN use-case — high cache-hit ratios, long TTLs, no per-user variance.
Dynamic acceleration: CDNs also help with genuinely dynamic, uncacheable responses. They maintain persistent, pre-authenticated TCP connections (with QUIC/HTTP3 increasingly) along optimised backbone routes between PoPs and your origin. Terminating TLS at the edge node (close to the user) removes multiple round trips of TLS handshake latency. The remaining origin fetch travels a shorter, higher-bandwidth path.
Edge compute: Modern CDNs (Cloudflare Workers, Fastly Compute(formerly Compute@Edge) ) run your code at the PoP — you can personalise responses, do A/B routing, or rewrite URLs without a round trip to origin. The execution environment is intentionally constrained (no persistent file system, tight CPU budgets) but latency is excellent.
The origin shield pattern
In a naive setup, a cache miss at any of hundreds of PoPs triggers an independent origin request. Under a sudden spike (a viral link, a TV ad), this becomes a thundering herd: thousands of simultaneous cache misses all hit origin at once. The solution is origin shielding (AWS: Origin Shield; Fastly: shielding PoP): designate one intermediate PoP as the sole gateway to origin. Other PoPs miss to the shield first, collapsing thousands of in-flight requests for the same object into one origin fetch.
Security functions
CDNs have become the de-facto DDoS mitigation layer. Because they absorb traffic at the edge — across a network with terabits of capacity — volumetric attacks (UDP floods, amplification) are absorbed before reaching origin. WAF (Web Application Firewall) rules, rate limiting, and bot management (Cloudflare's Bot Fight Mode, Fastly's Bot Management) all run at the PoP, protecting origin from malicious traffic without adding latency to legitimate requests.
What CDNs don't fix
A CDN cannot help with low-cache-hit-ratio workloads — private, authenticated, per-user API responses that must not be shared. Sending those through a CDN adds a network hop with no benefit. It also cannot fix a slow database query behind your origin; it just caches the slow result so subsequent users don't wait. And geo-routing means your users in São Paulo will never see your origin metrics unless you instrument the CDN's own logs — origin dashboards only see cache misses.