CDNs and Edge Delivery

Every extra millisecond of network latency between a user and your server is pure physics — the speed of light is a hard constraint. A CDN (Content Delivery Network) works around this not by making the network faster, but by making the data physically closer.

Without a CDN:
  User (Sydney) ─────────────────────────→ Origin server (Virginia)
                        ~230ms round trip

With a CDN:
  User (Sydney) ──────→ Edge cache (Sydney) ──(cache miss only)──→ Origin
                 ~10ms

A CDN is a network of edge servers distributed globally, each caching a copy of your static content (images, video, CSS/JS bundles, and increasingly full HTML pages) close to end users. The first request for a resource in a given region is a cache miss and goes to your origin server; every subsequent request in that region is served from the edge, orders of magnitude faster.

What belongs on a CDN

• Always: images, fonts, CSS, JS bundles, video — anything that's identical for every user.
• Often: fully static pages, or pages that are the same for all anonymous visitors.
• Rarely: personalized, per-user API responses — though even here, a short cache TTL (a few seconds) can meaningfully cut origin load for hot endpoints.

Cache invalidation at the edge

The same eviction/freshness problem from Chapter 2 shows up again here, at a larger scale: when you deploy a new version of a JS bundle, how do stale edge caches get updated? The standard answer is cache-busting via the filename — build tools hash the file's contents into its name (app.a3f9c1.js), so a content change produces a new URL rather than requiring you to invalidate an old one. Pages that must invalidate directly (a news article being corrected) use short TTLs or an explicit purge API most CDN providers expose.