CDNs and Edge Caching
You'll learn to
- -Explain what a CDN does and why it reduces latency
- -Know what content is safe to put on a CDN and what is not
- -Understand the core challenge of CDN caching: invalidation
Every request so far in this module has assumed the client talks directly to your origin server. But if your server lives in Virginia and a user is in Mumbai, physics alone (the speed of light through fiber-optic cable) adds real, unavoidable latency to every round trip. A Content Delivery Network solves this by placing copies of your content on servers scattered around the world, so users get served from nearby instead of from your one origin.
A user in Mumbai pays the full round-trip cost to Virginia on every single request.
Most requests never leave the region; only the rare cache miss pays the long round trip.
CDNs cache your content at 300+ edge locations worldwide so users get sub-50ms responses instead of 500ms round trips to your origin.
Your warehouse is in Dallas. Shipping a package from Dallas to Tokyo takes 14 days. So you pre-position inventory in Tokyo, Singapore, London, and São Paulo. Now Tokyo customers get 1-day delivery from your regional warehouse. A CDN is the same idea for bits. Your origin server is the warehouse, PoPs (Points of Presence) are regional warehouses.
A CDN is a geographically distributed network of servers (called edge nodes or PoPs - Points of Presence). When a user requests an asset, DNS routes them to the nearest edge node. If the edge has the content in cache (a HIT), it serves immediately. If not (a MISS), it fetches from your origin, caches, and serves.
What to cache: Static assets - images, CSS, JavaScript, videos, PDFs, font files. Also API responses with appropriate Cache-Control headers (public, max-age=3600). Do NOT cache: authenticated responses, dynamic personalized content, session data.
Cache-Control headers are the contract between your server and the CDN: `Cache-Control: public, max-age=31536000, immutable` = cache forever (for content-hashed assets like bundle.abc123.js). `Cache-Control: no-store` = never cache. `Cache-Control: public, s-maxage=0, stale-while-revalidate=86400` = CDN revalidates in background while serving stale.
Cache invalidation: When you update an asset, you need to purge the CDN cache or the old version will be served until TTL expires. Solutions: (1) Content-hash filenames (bundle.abc123.js → bundle.def456.js on change - never need to invalidate), (2) API calls to CDN purge endpoint (Cloudflare: instant, CloudFront: ~60s).
CDN as DDoS protection: A CDN absorbs volumetric DDoS attacks at the edge, far from your origin. Cloudflare has processed 71 million HTTP requests/second during DDoS events without impacting origin servers. Your 2-box origin could never survive that.
- -Use content-hashed filenames for all static assets (built by Vite/webpack automatically).
- -Set immutable on versioned assets - browsers and CDNs will never re-check them.
- -S3 + CloudFront is the standard AWS static hosting pattern.
- -CDN Geography: Cloudflare 300+ PoPs, CloudFront 400+ PoPs, Fastly 60+ PoPs.
- -HTTP/2 multiplexing and HTTP/3 (QUIC) reduce connection overhead - CDNs support these.
You just deployed a new version of your logo image, same filename. Users still see the old one. Why, and how do you fix it?
"I'd tell the CDN to clear its cache."
"Manually purging works but doesn't scale and is easy to forget. Better: serve versioned, content-hashed filenames (logo.a1b2c3.png), set Cache-Control: immutable on them, and update the reference to the new filename on deploy. The old file simply ages out of cache naturally; there's nothing to invalidate because nothing ever changes at a given URL."
What problem does a CDN primarily solve?
You now have every piece needed for Level 1: The Static App - a Client, DNS, and a CDN serving assets. Go place them on the canvas and see the request flow you just read about become something you can actually run.