Content Delivery Network (CDN)

What is a CDN?

A CDN stores copies of static assets — images, JavaScript, CSS, videos — on servers around the world. When a user in Tokyo requests your site, they often receive files from a nearby edge node instead of your origin server in Virginia.

How it works

1. First request for a file may go to your origin (S3, web server, etc.)
2. The CDN caches the response at the edge
3. Subsequent requests are served from cache until TTL expires

Benefits

• Lower latency — shorter physical distance to content
• Reduced origin load — fewer hits to your primary infrastructure
• DDoS absorption — large CDNs can absorb traffic spikes at the edge
• TLS termination — certificates managed at edge locations

What CDNs cache well

Static files, public API GET responses (with correct cache headers), and streaming video segments. Dynamic personalized pages usually bypass cache or use short TTLs.

Popular providers

Cloudflare, Fastly, Akamai, Amazon CloudFront, Azure CDN, and Google Cloud CDN. Many teams use a CDN in front of object storage for global static hosting.

Cost reality

CDNs are usually the cheapest bandwidth you can buy — often cheaper than serving from your origin, since cached hits never touch your servers. The catches: per-request fees add up on millions of tiny files, and misconfigured cache headers quietly send everything to the origin at full price. Check your cache hit ratio monthly; below ~80% for static-heavy sites means money is leaking.

What people get wrong

• Caching without a purge plan. Deploying new JS while the CDN serves week-old copies is the classic “works on my machine, broken for users” incident — version your asset filenames.
• Trusting default headers. No Cache-Control often means no caching; the CDN becomes an expensive pass-through.
• Putting authenticated, personalized pages behind aggressive caching. One user seeing another’s account page is a breach, not a bug.