Beating the Speed of Light

No matter how optimized your web server code is, it cannot break the laws of physics. Data traveling through fiber optic cables takes time. If your primary server is in New York, a user in Sydney, Australia will experience a baseline latency of ~200-250 milliseconds per round trip. Loading a webpage with 20 images could take seconds just due to geographical distance.

A Content Delivery Network (CDN) solves the physics problem by heavily caching your static assets on hundreds of servers (Edge Nodes) physically located all around the globe.

How a CDN Works (The Pull Model)

  1. The Setup: You configure your DNS so images.example.com points to the CDN (like Cloudflare, AWS CloudFront, or Fastly), not your actual server. You configure the CDN to point to your Origin Server (your real server in New York).
  2. The First Request (Cache Miss): A user in Sydney requests images.example.com/logo.png. They are routed via Anycast DNS to the closest CDN Edge Node in Sydney. The Sydney node doesn't have the image. It holds the user, reaches across the ocean to your Origin Server in NY, downloads the image, saves a copy to its local hard drive, and serves it to the user. This request is slow.
  3. Subsequent Requests (Cache Hit): A second user in Sydney requests the same image. The Sydney edge node already has it on disk. It serves it instantly in 10 milliseconds. The request never touches your New York server.

Pull vs. Push

In the pull model, edge nodes fetch content from origin on demand (the diagram above). It requires no upfront work and naturally caches only what is popular. In the push model, you upload content to the CDN in advance—useful for large video libraries or known launch assets that must be warm immediately.

Anycast Routing

Most CDNs use Anycast: many edge servers worldwide advertise the same IP address, and the internet's routing naturally delivers each user's packets to the topologically nearest one. If an edge location fails, BGP withdraws its route and traffic shifts to the next nearest—built-in failover at the network layer.

The Origin Shield

Without protection, every edge cache miss hits your origin. A regional origin shield is an intermediate caching layer: edges fetch through the shield, and the shield fetches from origin. This collapses a thousand simultaneous edge misses into a single origin request and protects the origin from cache-miss stampedes.

Benefits Beyond Latency

  • Massive Cost Savings: Egress bandwidth from AWS EC2 is extremely expensive. Serving 90% of your traffic from a CDN offloads that bandwidth.
  • DDoS Protection: If a botnet launches a 500 Gbps volumetric attack against your domain, the CDN absorbs the traffic across its massive global network. Your Origin server never even notices.
  • High Availability: If your Origin server briefly crashes, the CDN can often serve a "Stale" cached version of your site to users while you reboot the server.

Cache Invalidation Strategy

The hardest problem in computer science is cache invalidation. If you update your logo.png on the Origin server, the Sydney node will still serve the old cached version until its TTL (Time To Live) expires. To fix this, modern web development relies on Cache Busting / Fingerprinting. Build tools (like Webpack or Vite) append a hash to the filename upon compilation (e.g., main.a7f2b9.css). Because the URL is entirely new, the CDN treats it as a new file, guaranteeing the user gets the latest code instantly, allowing you to set infinite TTLs for performance.

Most CDNs also expose an API purge for emergencies, but it is slow to propagate to every edge and should be a last resort, not your deployment strategy.