Content Delivery Networks (CDN)

Chapter 04 · Scaling Systems

A CDN (Content Delivery Network) caches your content at edge servers around the world. Users get content from the nearest edge instead of your origin. Cheaper, faster, more resilient.

The latency-of-light problem

Light goes about 300,000 km/sec. Round-trip from New York to Sydney: roughly 200ms minimum, before any server even processes the request. If your origin server is in Virginia and your user is in Mumbai, every request pays this tax. Always.

A CDN moves your content closer to the user. Edge servers spread across hundreds of cities cache static assets. The user fetches from the nearest edge instead of the origin. Latency drops from 200ms to 20ms.

What gets cached

Anything that doesn't change per user, ideally with a long lifetime:

Images, videos, JS bundles, CSS, fonts.
HTML for pages that are the same for all visitors (marketing sites, blog posts).
API responses for slowly-changing data (product catalog, public profiles).

What does not get cached: per-user data (your inbox), real-time data (current stock prices), data with strong consistency requirements (account balance).

CDN edge servers absorb most traffic. The origin only sees cache misses.

How a CDN actually works

User makes a request. DNS routes them to the nearest CDN edge.
Edge checks its cache. If hit, return immediately.
If miss, edge fetches from origin (or another regional cache), stores it, returns it.
Subsequent users at that edge get the cached copy.

The cache lifetime is controlled by HTTP Cache-Control headers. max-age=3600 means the edge can serve this for an hour without checking with origin.

Push vs pull CDN

Pull (most common): the CDN fetches from your origin on first request. Lazy. Auto-updates when origin changes (after expiration).

Push: you upload content to the CDN proactively. More control, used for video and large file distribution.

Cache invalidation

Phil Karlton's famous quote: there are only two hard things in computer science, cache invalidation and naming things. CDN edges may serve stale content for hours unless you invalidate. Three approaches:

TTL expiry. Set short TTLs and accept some staleness.
Manual purge. When something changes, call the CDN API to evict that URL.
Versioned URLs. Embed a hash in the URL (app.4f8a2b.js). New version, new URL, no invalidation needed. The standard for static assets.

Beyond static content

Modern CDNs (Cloudflare, Fastly, AWS CloudFront with Lambda@Edge) run code at the edge. You can do auth, A/B testing, request transformation, even render full pages, all milliseconds from the user. This blurs the line between CDN and application server.

The first thing to add when traffic grows CDN should be the first piece of infrastructure you add as soon as you have global users. The latency win is huge, the cost is low (often cheaper than serving from origin), and the protection from traffic spikes is a bonus. Cloudflare's free tier is enough for most small sites.

What to remember

A CDN reduces latency by serving from edges close to users, reduces cost by absorbing traffic before it hits your origin, and adds resilience because your origin can be down briefly while users still hit the cache. For any serious public-facing system, a CDN is not optional.

← Previous

Reverse Proxy and Forward Proxy

Caching Strategies