How CDNs Work
The Internet's Secret Superpower 🌐

A Content Delivery Network (CDN) is a geographically distributed network of servers that work together to deliver content to users as fast as possible. Instead of every user fetching content from one central server (which could be thousands of miles away), CDNs place copies of that content on servers all around the world. 🌍

The Numbers Are Staggering 🤯

What CDNs Actually Deliver

CDNs aren't just for images. They deliver almost everything you interact with online:

• Static assets: Images, CSS, JavaScript, fonts
• Video streaming: Netflix, YouTube, Twitch (this is huge!)
• Software downloads: Windows updates, game patches, app installers
• API responses: Cached API data for faster responses
• Entire websites: Static sites, JAMstack applications
• Live streams: Sports events, concerts, gaming

To truly appreciate CDNs, let's imagine a world without them. Spoiler: it's not pretty. 😬

The Problem: Physics is Undefeated

Data travels through fiber optic cables at about 2/3 the speed of light. Sounds fast, right? But the Earth is big, and those milliseconds add up:

And that's just one round trip! A typical web page requires dozens of requests (HTML, CSS, JS, images, fonts, API calls). Without a CDN, each request has to travel across the world.

What Happens to Your Website

Other Problems Without CDNs

• Server overload: One server handling all global traffic = crashes during traffic spikes
• Single point of failure: If your origin server goes down, everyone is affected
• Bandwidth costs: Serving everything from one location = massive bandwidth bills
• DDoS vulnerability: One target to attack = easy to take down

Now let's look at how CDNs are actually built. Understanding this architecture is key to understanding how they work! 🏗️

The Three-Tier Architecture

What's Inside an Edge Server?

Edge servers are specialized machines optimized for one thing: serving cached content incredibly fast. Here's what's typically inside:

Points of Presence (PoPs) Explained

A PoP (Point of Presence) is a physical location where a CDN has deployed servers. Think of it as a "franchise location" for your content. 🏪

Major CDN providers have PoPs strategically placed:

• Major cities: New York, London, Tokyo, Sydney, etc.
• Internet exchange points (IXPs): Where ISPs interconnect
• Inside ISP networks: Some CDNs (like Netflix Open Connect) deploy servers directly inside ISP data centers

Caching is the heart of CDN technology. Let's understand exactly how it works — this is where it gets really interesting! 🎯

The Cache Key

When the CDN receives a request, it needs to decide: "Do I have this content already?" It does this by computing a cache key — a unique identifier for the content.

// A cache key is typically built from:

cacheKey = hash(
    url,              // https://example.com/images/hero.jpg
    queryParams,       // ?v=1.2.3
    headers,           // Accept-Encoding, Accept-Language (if Vary)
    cookies            // Sometimes (careful with this!)
)

// Example cache key:
"example.com/images/hero.jpg?v=1.2.3|gzip|en-US"

Cache HIT vs MISS

Cache-Control Headers

Your origin server tells the CDN how to cache content using HTTP headers. This is crucial — get it wrong, and you'll either serve stale content or have terrible cache hit rates. 😬

// Tell CDN to cache for 1 year (immutable assets)
Cache-Control: public, max-age=31536000, immutable

// Tell CDN to cache for 1 hour
Cache-Control: public, max-age=3600

// Tell CDN to revalidate before serving
Cache-Control: public, max-age=0, must-revalidate

// Tell CDN NOT to cache (private user data)
Cache-Control: private, no-store

// Vary header: cache different versions based on header
Vary: Accept-Encoding, Accept-Language

Cache Tiers (Memory vs Disk)

Edge servers typically have multiple cache tiers:

How does a user's request magically reach the "nearest" edge server? This is one of the most clever parts of CDN architecture! 🧭

Method 1: DNS-Based Routing

The most common approach. When you configure your domain to use a CDN, DNS queries return different IP addresses based on where the user is located.

# User in New York queries cdn.example.com
$ dig cdn.example.com

;; ANSWER SECTION:
cdn.example.com.    60    IN    A    198.41.215.162  // NYC edge

# Same query from user in Tokyo
cdn.example.com.    60    IN    A    104.18.32.7     // Tokyo edge

The CDN's DNS servers use several signals to pick the best edge:

• GeoDNS: Maps user's resolver IP to geographic location
• Latency measurements: Real-time latency data between resolvers and edges
• Server health: Avoids overloaded or unhealthy servers
• Network topology: Considers BGP routes and peering

Method 2: Anycast Routing

A more elegant approach used by Cloudflare and others. Multiple servers around the world share the same IP address, and BGP routing automatically sends users to the nearest one!

DNS vs Anycast Comparison

There's a famous quote in computer science: "There are only two hard things in Computer Science: cache invalidation and naming things." Let's see why cache invalidation is so tricky! 🤔

The Problem

You've cached an image at 300+ edge servers worldwide. Now you need to update it. How do you ensure all users see the new version immediately?

Strategy 1: Cache Busting (Versioned URLs)

The most reliable approach: change the URL when the content changes.

<!-- Instead of this (hard to invalidate): -->
<link href="/styles/main.css">
<img src="/images/hero.jpg">

<!-- Do this (easy to invalidate): -->
<link href="/styles/main.v2.3.1.css">
<img src="/images/hero.abc123.jpg">

<!-- Or use query strings: -->
<link href="/styles/main.css?v=2.3.1">

When you deploy new content, you generate a new filename (using content hash or version number). Old cached content stays cached (harmlessly), new content gets cached fresh.

Strategy 2: Purge API

CDNs provide APIs to manually invalidate cached content:

# Cloudflare - Purge specific files
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/images/hero.jpg"]}'

# Purge everything (nuclear option)
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" \
  --data '{"purge_everything":true}'

Strategy 3: Short TTLs + Stale-While-Revalidate

A clever middle ground: serve potentially stale content while fetching fresh content in the background.

// Content is "fresh" for 60 seconds
// After that, serve stale for up to 1 hour while revalidating in background
Cache-Control: public, max-age=60, stale-while-revalidate=3600

// How it works:
// t=0: Edge caches content
// t=30s: Request → Cache HIT (fresh)
// t=90s: Request → Cache HIT (stale, but served immediately)
//        Edge fetches fresh content from origin in background
// t=91s: Next request → Cache HIT (fresh again!)

Cache Invalidation Best Practices

Modern CDNs do way more than just cache content. They've evolved into comprehensive security platforms! 🛡️

DDoS Protection

CDNs are incredibly effective at absorbing DDoS attacks. Here's why:

Web Application Firewall (WAF)

CDNs can inspect and filter malicious requests before they reach your origin:

• SQL Injection: Blocks ' OR 1=1-- type attacks
• XSS (Cross-Site Scripting): Filters malicious JavaScript
• Rate Limiting: Prevents brute force attacks
• Bot Detection: Distinguishes humans from bots

// Block requests with SQL injection patterns
(http.request.uri.query contains "' OR '") or
(http.request.uri.query contains "1=1") or
(http.request.uri.query contains "UNION SELECT")

// Action: Block

SSL/TLS Termination

CDNs handle HTTPS encryption at the edge, which provides several benefits:

• Free SSL certificates: Most CDNs provide free certs via Let's Encrypt
• Reduced origin load: CPU-intensive TLS handshakes happen at the edge
• Latest protocols: CDNs support TLS 1.3, HTTP/2, HTTP/3 even if your origin doesn't

Edge Computing

The newest evolution: running your code directly on edge servers! 🚀

// A/B test at the edge - no origin round-trip!
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // 50% of users see variant A, 50% see variant B
  const variant = Math.random() > 0.5 ? 'A' : 'B'
  
  const url = new URL(request.url)
  url.pathname = `/variant-${variant}` + url.pathname
  
  return fetch(url)
}

Let's look at the major players in the CDN space and what makes each unique. 🏆

The Big Players

Specialized CDNs

• Netflix Open Connect: Netflix's private CDN with appliances inside ISPs
• YouTube's Infrastructure: Google's custom video delivery network
• Imgix / Cloudinary: Image-specific CDNs with on-the-fly transformations
• Mux / Cloudflare Stream: Video-specific CDNs with adaptive bitrate

Pricing Models

Rough pricing comparison (as of 2025):

• Cloudflare: Free tier (generous!), Pro from $20/mo
• Bunny CDN: ~$0.01/GB (very cheap)
• AWS CloudFront: ~$0.085/GB (first 10TB)
• Akamai: Enterprise pricing ($$$$)

CDNs are incredibly reliable, but when they fail, the impact is massive. Let's look at some notable outages and what we can learn from them. 💥

Notable CDN Outages

Why CDN Outages Are So Impactful

Multi-CDN Strategy

Large companies use multiple CDNs to avoid single points of failure:

# Primary CDN (70% of traffic)
cdn.example.com.    60    IN    CNAME    example.cloudflare.com.  weight=70

# Secondary CDN (30% of traffic)
cdn.example.com.    60    IN    CNAME    example.fastly.net.      weight=30

# If Cloudflare goes down, traffic automatically shifts to Fastly

Let's wrap up with the essential lessons about CDNs! 🎯

Quick Reference: CDN Configuration Checklist

Official Documentation

• Cloudflare Developers Documentation
• AWS CloudFront Documentation
• Fastly Documentation
• MDN: HTTP Caching

Technical Deep Dives

• Cloudflare Architecture Blog
• Netflix Open Connect — How Netflix built their CDN
• web.dev: HTTP Cache Guide

Incident Reports

• Cloudflare Nov 2025 Outage Deep Dive — Our analysis
• Fastly June 2021 Outage Summary

Found this helpful? Share it! 🚀