Why Distance Doesn't Matter (CDNs)

https://www.youtube.com/watch?v=M3rK2tZj8QM

You're in Tokyo. You want to watch a video. The server hosting it is in Virginia — twelve thousand kilometers away. Light itself takes forty milliseconds to make that trip, one way. And your data isn't light. It's hopping through routers, switches, undersea cables. A single round trip: two hundred milliseconds minimum.

Your browser needs to open a connection (one round trip), negotiate encryption (another), request the page (another). Before a single pixel loads, you've burned six hundred milliseconds on physics alone.

The speed of light has a speed limit. And one server can't be close to everyone. So what if we stopped trying?

Edge Servers: Branch Libraries for the Internet

Instead of one server, what if you had thousands? Spread across the planet.

That's a CDN — a Content Delivery Network. You take your content (images, videos, JavaScript, entire web pages) and copy it to servers in dozens of cities. Tokyo. Frankfurt. Mumbai. São Paulo.

These are edge servers. They sit at the edge of the network, close to users. When someone in Tokyo requests your video, they don't reach Virginia. They reach a server in Tokyo. Ten milliseconds away.

The origin server still exists — it's the source of truth in your data center. But edge servers are like branch libraries. You don't drive to the Library of Congress every time you want a book. You go to the one down the street.

Cloudflare runs servers in over 300 cities. Akamai runs over 4,000 locations. That twelve-thousand-kilometer trip becomes a two-kilometer trip to a server downtown.

Cache Hits and Misses

Edge servers aren't magic mirrors of your origin. They're caches. And caches have rules.

When a user requests a file, the edge checks: do I have this? If yes — cache hit. Served instantly. No origin involved.

If the edge doesn't have it — cache miss — it fetches from the origin, stores a copy, then serves the user. First request is slow. Every request after is fast.

This is why CDNs get better with traffic. More people requesting the same content means the edge already has it cached. Popular files stay warm. Obscure files miss every time.

One detail that trips people up: the cache key. The edge decides if two requests are for the "same" file based on the URL. Same URL, same cached response. But append a query parameter — a version number, a user ID — and the edge treats it as a different file entirely:

GET /styles.css          → cache HIT (already cached)
GET /styles.css?v=2      → cache MISS (different cache key)
GET /styles.css?user=42  → cache MISS (different cache key)

CDN engineers obsess over cache hit ratios. Ninety-five percent means only 5% of requests touch the origin. The origin barely has to work.

Cache Invalidation: The Hard Problem

There's a famous quote in computer science: there are only two hard things — cache invalidation and naming things.

You push a bug fix to production. Your origin has the new code. But three hundred edge servers still have the old version cached. Users are getting stale content. How do you fix this?

Option 1: TTL (Time to Live). Every cached file gets an expiration timer. When the TTL expires, the edge fetches a fresh copy.

Cache-Control: max-age=60

Simple. But there's a tradeoff — short TTLs mean more origin traffic. Long TTLs mean users see stale content longer.

Option 2: Purging. You tell the CDN to delete a file from every edge, right now. Instant in theory, but purging across thousands of servers takes a few seconds. Purge too aggressively and you nuke your cache hit rate.

Option 3: Stale-while-revalidate. The clever one. The edge serves the stale version immediately (fast response) but fetches a fresh copy in the background. Speed now, freshness next time.

Cache-Control: max-age=60, stale-while-revalidate=30

This tells the edge: "For the first 60 seconds, serve from cache. For the next 30 seconds after that, serve stale but revalidate in the background." The user never waits for the origin.

In practice, teams use all three. Short TTLs for API responses that change constantly. Long TTLs plus purging for static assets. Stale-while-revalidate for everything in between. There's no single right answer — that's what makes it hard.

How Your Browser Finds the Nearest Edge

You've got servers everywhere. Content is cached. But how does your browser know which edge server to talk to?

It starts with DNS. When you type a URL, your browser resolves the domain to an IP address. Normally, that IP points to one server. CDNs do something different.

GeoDNS looks at where the DNS request is coming from and returns the IP of the nearest edge. Request from Tokyo? Here's the Tokyo edge IP. Request from London? London's IP. Same domain, different answers depending on who's asking.

But the more powerful technique is anycast. With anycast, every edge server advertises the same IP address. When your request enters the internet, BGP (the routing protocol that glues the internet together) naturally delivers it to the closest server advertising that IP.

No special DNS logic needed. The network itself makes the routing decision.

Anycast is elegant because it handles failures automatically. If a server goes down, its BGP route disappears. Traffic flows to the next closest server. No DNS update. No propagation delay. Just instant failover.

This is how Cloudflare, Google, and most modern CDNs work. One IP address, three hundred cities. The internet's routing fabric does the rest.

The Speed of Light Is Still the Limit

CDNs don't break physics. Light still has a speed limit. But CDNs make the distance irrelevant by putting your content close enough that it doesn't matter. The twelve-thousand-kilometer problem becomes a two-kilometer solution — not by making the network faster, but by making the network shorter.

Watch the full animated breakdown: Why Distance Doesn't Matter (CDNs)

---

Neural Download — visual mental models for the systems you use but don't fully understand.