CDN — Part 1: Foundations & Core Concepts

What is this?

Imagine your favorite coffee chain decided to brew every cup at one giant roastery in Seattle and ship it to you on demand. Order a latte in Mumbai and you'd wait days for it to cross an ocean — cold, late, and miserable. So they don't do that. Instead they put a shop on practically every corner, each holding the same beans and the same recipe, so the cup you want is almost always made a few hundred meters away. You never drive across town, let alone across the planet.

A Content Delivery Network (CDN) is that chain of corner shops for your website's content. Instead of every user fetching your images, videos, scripts, and pages from one origin server far away, the CDN keeps copies on hundreds of servers spread across the globe — and serves each user from the one nearest to them.

The one-line idea: a CDN puts copies of your content physically close to your users — turning a slow trip across the planet into a fast trip across town, and shielding your origin from the flood.

That single move — content near the user — is the whole game. Everything in this chapter unpacks why it matters and how it actually works. We'll keep coming back to the coffee-shop image: corner shops are edge PoPs, a regional warehouse is the mid-tier, and the central roastery is your origin.

---

1. Why a CDN exists: you can't outrun the speed of light

Here's the uncomfortable truth that created the entire CDN industry: light is slow. Not slow in everyday terms, but slow when a signal has to cross continents and back, many times, for a single page load.

Data travels through fiber at roughly 200,000 km/s — about two-thirds the speed of light in a vacuum. That's a hard physical floor. No amount of money, faster servers, or clever code makes a photon move faster. So distance translates directly into delay, and you can do the arithmetic yourself:

Round-trip time (RTT) ≈ 2 × distance ÷ speed

If your origin sits in Virginia, here's the unavoidable minimum just for the signal to get there and back — before your server does a single byte of work:

User location	Distance to Virginia	Minimum RTT (just the light)
New York	~530 km	~5 ms
London	~5,900 km	~60 ms
Tokyo	~10,900 km	~110 ms
Mumbai	~13,000 km	~130 ms
Sydney	~16,000 km	~160 ms

And that's the floor. Real networks add router hops, congestion, and TLS handshakes — and a single web page might make dozens of these round trips. A 130 ms floor quietly becomes a second of waiting.

The CDN's answer is elegant precisely because it doesn't fight physics — it sidesteps it. If you can't make light faster, shorten the distance. Put a copy of the content in Mumbai, and the Mumbai user's 130 ms trip collapses to a few milliseconds. You didn't speed up the signal; you just stopped sending it so far.

💡 This is the mental anchor for the whole topic: a CDN doesn't make your origin faster. It makes most requests never reach your origin at all.

---

2. The layered architecture: edge, mid-tier, shield, origin

A CDN isn't one ring of servers — it's a hierarchy of caches, each layer catching what the layer above it missed. Think of it as a supply chain: the corner shop, the regional warehouse, and the central roastery.

Walk a request down the chain:

• Edge PoP (the corner shop). A Point of Presence is a cluster of CDN servers in a specific city. This is the layer the user actually talks to, and it handles the overwhelming majority of traffic — popular content (your logo, your CSS, today's hot video) lives here and is served in single-digit milliseconds.
• Regional mid-tier (the warehouse). If the edge doesn't have it, it asks a larger regional cache. This catches content that's popular somewhere in the region but not at every single corner — and it means dozens of edge PoPs in Europe can share one cached copy instead of each fetching its own from across the ocean.
• Origin shield (the chokepoint, on purpose). Here's the clever bit. You funnel all misses through a single designated cache before they're allowed to reach the origin. Why deliberately create a bottleneck? Because it collapses the thundering herd: if 50 edge PoPs all miss the same brand-new video at once, without a shield you'd get 50 simultaneous requests slamming your origin. With a shield, the first one fetches it, and the other 49 get the now-cached copy. Your origin sees one request, not fifty.
• Origin (the roastery). Your actual servers. By the time a request reaches here, it's already been filtered four times. A well-tuned CDN can cut origin traffic by 95% or more — which is often the difference between needing a fleet of origin servers and needing a handful.

💡 Notice the shape: each layer trades a little extra latency (one more hop) for a big drop in load on the layer below. The edge optimizes for speed; everything beneath it optimizes for protecting the origin.

This hierarchy is the backbone we'll build on in Part 2. For now, hold onto the percentages — they're roughly what a healthy CDN looks like, and interviewers love when you can reason about where a request gets served.

---

3. How a request finds the nearest PoP: DNS and Anycast

We keep saying "the nearest PoP" — but how does a user in Mumbai actually get routed to the Mumbai shop instead of the Virginia one? They typed the same URL everyone else did. The magic happens at the routing layer, and there are two main techniques.

3.1 GeoDNS — answer the question differently depending on who's asking

When your browser resolves cdn.example.com, it asks a DNS server "what's the IP for this name?" A CDN's authoritative DNS is sneaky: it looks at where the question came from and hands back a different answer accordingly.

Ask from India, get the Mumbai PoP. Ask from the UK, get London. Same name, location-aware answer. The CDN's DNS also factors in PoP health and load — if Mumbai is down or overloaded, it quietly hands you the next-best PoP instead. The user never knows.

3.2 Anycast — let the internet's own routing do the work

The second technique is subtler and almost magical. With Anycast, the CDN announces the same IP address from many PoPs around the world at once. The internet's core routing protocol (BGP) treats this as "this destination exists in many places" and naturally forwards your packets to the topologically closest one.

So every user connects to, say, 198.51.100.1 — but a packet from Tokyo lands in the Tokyo PoP and a packet from Berlin lands in Frankfurt, with no per-user logic at all. The network sorts it out. As a bonus, Anycast is a natural DDoS sponge: an attack flooding that one IP gets spread across every PoP on the planet instead of concentrating on one.

In practice, big CDNs combine both — GeoDNS to pick a region, Anycast for fast, resilient routing within it.

⚠️ A subtle trap: DNS answers are cached, and the resolver's location isn't always the user's location (think a user in Africa configured to use a US-based public resolver). That mismatch can route someone to a far-away PoP. The fix is the EDNS Client Subnet extension, which passes a hint of the real client's network — a great detail to drop in an interview.

---

4. Caching: the part that makes it all work

Routing gets the user to a nearby PoP. But a nearby PoP only helps if it already has the content — otherwise it still has to trek back to the origin. So the heart of a CDN is caching: deciding what to keep, for how long, and when to throw it away.

Let's trace the fundamental loop. A request arrives at an edge PoP:

• A cache HIT means the PoP already has a fresh copy — it serves instantly. This is the fast, cheap, happy path.
• A cache MISS means it has to fetch from the origin (paying that full latency once), store a copy, and serve it. The next user gets a HIT.

The single most important number in CDN-land falls right out of this: the Cache Hit Ratio (CHR) — the fraction of requests served from cache without bothering the origin. A 95% CHR means only 1 in 20 requests pays the full origin round trip. Push CHR up and everything gets better at once: latency drops, origin load drops, and your bandwidth bill drops.

4.1 Who decides what's cacheable? HTTP headers.

The origin tells the CDN how to treat each response using HTTP caching headers. These aren't CDN-specific magic — they're the same standard headers browsers have used for decades:

• Cache-Control: max-age=3600 — "this is good for 3,600 seconds." That number is the TTL (time-to-live): how long the cached copy stays fresh before the CDN must re-check it. (A common refinement: s-maxage sets a separate, usually longer TTL for shared caches like the CDN, while max-age governs the user's own browser — so the edge can hold a copy for an hour while the browser only trusts it for a minute.)
• Cache-Control: no-store — "never cache this" (e.g. a bank balance, a personalized page).
• Cache-Control: immutable — "this will never change, don't even bother revalidating." Perfect for versioned assets (more in a second).
• ETag / Last-Modified — a fingerprint or timestamp. When a cached copy goes stale, instead of re-downloading the whole thing, the CDN asks the origin "still the same as ETag: abc123?" If yes, the origin replies 304 Not Modified — a tiny response, no body, big bandwidth savings.

4.2 Stale-while-revalidate: serve fast, refresh quietly

A lovely trick worth knowing by name. With stale-while-revalidate, when content expires the CDN serves the slightly stale copy immediately to the waiting user, then refreshes it from origin in the background. The user never waits for the revalidation — they get a fast (marginally old) response, and the next user gets the fresh one. It's "good enough, right now" beating "perfect, in 130 ms."

4.3 The cache key: what counts as "the same content"?

When the CDN looks up whether it has a HIT, it hashes the request into a cache key — usually the URL. But you can include or exclude more: query parameters, certain headers, device type. This is a quiet source of trouble.

Imagine your URLs carry a tracking parameter: /article?utm_source=twitter vs /article?utm_source=email. If the cache key includes the full query string, those are two different keys for identical content — you've just split your cache and tanked your hit ratio. Put a number on it: an article shared across five campaigns (twitter, email, facebook, newsletter, push) becomes five separate cache entries, so the first visitor on each link pays an origin miss. One article, five misses where there should have been one — multiply that across a catalog and a busy news day, and a key bug alone can drag a 95% hit ratio down into the 70s. The fix is to normalize keys: strip parameters that don't change the response. Conversely, if a page genuinely differs by, say, Accept-Language, you must vary on it or you'll serve French content to English users. Getting the cache key right is one of the highest-leverage tuning knobs a CDN has — we'll return to it in Part 2.

---

5. Cache invalidation: the genuinely hard part

There's an old joke that there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. The joke is funny; the first one is real. You've spread copies of your content across hundreds of PoPs worldwide. Now you change something. How do you make every PoP forget the old version — fast, and without overwhelming your origin? There are three strategies, in increasing order of how much we love them.

• TTL expiry — just wait it out. Set a short TTL and stale content fixes itself when the timer runs out. Dead simple, zero machinery. But it's a blunt instrument: short TTLs mean more origin traffic, and you're still serving the old version until the clock ticks over. Fine for content that changes on a predictable schedule.
• Active purge — tell the edges to forget. You call the CDN's purge API ("drop /logo.png everywhere") and it broadcasts a forget-this command to every PoP. Fast and precise, but propagating a purge to hundreds of PoPs globally takes a moment, and a careless mass purge can trigger a thundering herd as every edge re-fetches at once. Use it for "we shipped a bad file, kill it now" moments.
• Versioned URLs — the move that makes invalidation disappear. This is the senior answer. Instead of ever changing the content at a URL, you change the URL when the content changes: style.css becomes style.a1b2c3.css (a hash of the contents). Now you can mark these files immutable with a one-year TTL, because they will never change — a different file gets a different name. Need to ship a new version? Reference the new filename in your HTML. The old one just ages out, unused. There's nothing to invalidate, because you never overwrite anything.

💡 The principle behind versioning is profound and worth internalizing: the easiest invalidation problem is the one you designed away. If a URL's content can never change, you never have to invalidate it. Most high-performing sites version every static asset for exactly this reason.

---

6. A worked example: what a CDN actually buys you

Let's make the payoff concrete. Say you run a media site. Origin in Virginia. A user in Sydney loads a page: 1 HTML document, 1 CSS file, 1 JS bundle, and 8 images.

Without a CDN, every one of those 11 assets is a round trip to Virginia at ~160 ms each. Even with some parallelism, you're looking at the better part of a second of pure network latency — before rendering, before anything. The page feels sluggish, and your origin in Virginia just handled 11 requests for one page view, multiplied by every visitor on Earth.

With a CDN at 95% CHR, a Sydney edge PoP serves those static assets in ~5 ms each. The numbers flip:

	Without CDN	With CDN (Sydney edge)
Latency per asset	~160 ms	~5 ms
Origin requests per page view	11	~0.5 (mostly HITs)
Felt page load	sluggish, ~1 s of latency	snappy, tens of ms
Origin fleet needed	large	small

The win is doubled: the user gets a dramatically faster experience, and your origin gets shielded from the bulk of the traffic. Faster and cheaper is rare in engineering — the CDN is one of the few places you genuinely get both.

---

7. Key takeaways

1. A CDN exists to beat one enemy you can't out-engineer — the speed of light. It doesn't make signals faster; it shortens the distance by serving content from a PoP near the user.
2. The architecture is a cache hierarchy: edge PoPs (the corner shops) handle ~85-95% of traffic, with mid-tier and origin shield layers catching misses and protecting the origin from thundering herds.
3. Users reach the nearest PoP via GeoDNS (location-aware DNS answers) and Anycast (the same IP announced everywhere, routed by the network itself).
4. The heart of a CDN is caching, governed by HTTP headers (Cache-Control, TTL, ETag). The number that rules them all is the Cache Hit Ratio — push it up and latency, origin load, and bandwidth cost all drop together.
5. Cache invalidation is the hard part. TTL is simplest, purge is fast-but-costly, and versioned URLs are the senior move — they make the invalidation problem disappear entirely.

Next up, Part 2 cracks open the architecture: how the cache hierarchy is engineered, the eviction algorithms that decide what to keep, invalidation at scale, and the rise of edge compute — running your code, not just caching your files, at the edge.