Content Delivery Networks (CDNs)

The failure mode CDNs solve is deceptively simple: the internet is physical. A user in Singapore fetching a 4 MB hero image from an origin in Virginia pays for many network hops, multiple round trips, and trans-ocean congestion. Multiply that by millions of page views and your origin spends its day serving identical bytes again and again.

User in Mumbai ───────┐
User in Paris  ───────┼──▶ origin.example.com ──▶ app / S3
User in Sydney ───────┘        (same logo, same CSS, same video chunk)

• High latency: even small files feel slow when the TCP/TLS handshake and bytes cross continents.
• Origin hot spots: one viral asset can saturate your storage bucket, web server, or load balancer.
• Expensive repeated work: the same public image, script, or video segment is fetched thousands of times when it could be fetched once per region and reused.

A CDN operates many edge POPs in large internet exchange locations. When a browser requests https://cdn.example.com/app.8fd1.css, DNS and/or anycast routing steer the request to a nearby healthy POP. Anycast lets many POPs advertise the same IP prefix; internet routers naturally choose the shortest available path.

1. Browser requests /images/hero.jpg from cdn.example.com
2. Anycast/DNS routes the browser to a nearby edge POP
3. Edge checks its cache key: host + path + selected query/header values
4. HIT: edge returns bytes immediately
5. MISS: edge fetches from origin, stores the response with its TTL, then returns it

The cache key is important. If you include every query parameter or cookie, two users may produce different keys for identical content and destroy the hit rate. If you ignore a header that changes the response, such as language or image format, you may serve the wrong variant.

CDNs are best for content that is expensive to move and safe to reuse: images, fonts, JavaScript and CSS bundles, downloadable files, video segments, public product photos, documentation assets, and selected API responses. The origin tells the edge how long a response can be reused with HTTP caching headers.

# fingerprinted build artifact: safe for a year because URL changes on deploy
Cache-Control: public, max-age=31536000, immutable

# product image that may be replaced: cache briefly and revalidate
Cache-Control: public, max-age=300, stale-while-revalidate=60

# private dashboard JSON: do not share through a public CDN cache
Cache-Control: private, no-store

Most web CDNs are pull CDNs: the edge pulls content from the origin on the first miss. A push CDN requires you to upload content to the CDN ahead of time. Pull is operationally simpler for web assets; push can be useful for very large media libraries and workflows where publishing is explicit.

Many CDNs also support origin shielding: instead of every edge POP fetching from your origin during a global miss storm, all edges fetch through one regional shield cache. The shield collapses duplicate misses, so your S3 bucket or origin server sees one refill rather than thousands.

many edge POPs miss /trailer.mp4 at once
          │
          ▼
   regional shield cache  ── one fetch ──▶ origin
          │
          └─ fills edges as they request the object

Cache invalidation is the price of caching. If the origin changes a file while edges still have a fresh copy, users may see stale bytes until the TTL expires. You have three common tools: wait for TTL, deploy a new versioned URL, or explicitly purge the old cache entry.

• Purge by URL: fast for a small set of known objects, such as one incorrect image.
• Purge by prefix or tag: useful for a product category or tenant, but can be slower or costlier.
• Soft purge: marks content stale so the next request revalidates, often safer than deleting everything at once.

Private content can still use a CDN, but access control must move to the edge. Use signed URLs or signed cookies that encode an expiry, allowed path, and sometimes IP or policy claims. The CDN verifies the signature before serving the cached object, while the origin remains hidden and protected.

GET https://cdn.example.com/private/video/lesson-42.m3u8
  ?expires=1790000000
  &policy=path:/private/video/lesson-42/*
  &signature=HMAC(policy + expires)

• Next.js assets: hashed JavaScript chunks, CSS, and images are ideal long-TTL CDN content.
• Video streaming: HLS/DASH manifests and segments are cached at the edge so seeking and playback avoid origin round trips.
• Software downloads: release binaries and installers use CDNs to avoid melting one origin during launch day.
• Private training content: the object is cached, but only users with valid signed URLs or cookies can access it.