Skip to content

CDN (Content Delivery Network)

A server in Frankfurt answering a request from Tashkent doesn't just send data — it sends it across roughly 4,500 kilometers of cable and however many routers sit along that path, and each hop adds a few milliseconds that add up. Physical distance alone puts a hard floor under how fast a response can possibly arrive, no matter how fast the server or the connection is — a limit this course works out in exact numbers later on. A CDN's entire premise is a direct answer to that cost: instead of one server far from most of its visitors, put copies of the content on servers physically close to wherever visitors actually are, and answer each request from whichever copy is nearest.

The problem before CDNs existed

In the web's early years, a website ran on one server, or a small cluster, in one physical location — and every visitor, no matter where they were in the world, made the same long trip to reach it. A user in Tashkent loading a site hosted in Virginia paid the full round-trip cost of that distance on every single request: every image, every script, every stylesheet. As the web grew from mostly text into pages loaded with images, video, and dozens of separate assets per page, that per-request distance cost stopped being a minor inconvenience and became the largest single factor in how slow a page felt to load, especially for visitors far from wherever the site happened to be hosted.

The fix that emerged, as commercial CDN services began appearing in the late 1990s, was to stop treating "the server" as one place at all. A CDN is a geographically distributed network of servers, called edge servers or points of presence (PoPs), that each hold a cached copy of a site's content. A visitor's request gets routed to whichever edge server is closest to them, rather than all the way to the original server, cutting most of the physical distance — and therefore most of the latency — out of the trip.

Without a CDN:
  Visitor in Tashkent ──────────────────────────▶ Origin server in Virginia
                              ~11,000 km, every request

With a CDN:
  Visitor in Tashkent ──▶ Nearby edge server (Almaty, Istanbul...) ──▶ Origin server (only when needed)
                              a few hundred km, most requests never go further

How a request finds the nearest edge server

The mechanism a CDN uses to route each visitor to a nearby edge server is DNS itself, and it works because of something already covered: the DNS resolution process doesn't guarantee every resolver gets the same answer for the same name. A CDN's authoritative name servers deliberately exploit that. When a recursive resolver in Tashkent asks for cdn.example.com's A record, the CDN's authoritative server can see which resolver is asking — and, from that resolver's own location, infer roughly where the actual client is — and return the IP address of an edge server near Tashkent. The identical query from a resolver in Berlin gets a completely different A record back, pointing at an edge server near Berlin.

dig cdn.example.com A

;; ANSWER SECTION:
cdn.example.com.    60    IN    A    104.18.22.5

That same command run from a different country would often return a different address entirely — not because the domain changed, but because the CDN's DNS layer is actively steering each resolver toward a different physical server. This is why a CDN edge server's IP address isn't something to hardcode or rely on staying fixed; the whole system depends on that mapping being free to change as conditions do.

Some CDNs use a second technique alongside or instead of DNS-based steering: anycast, where the exact same IP address is announced from many physical locations simultaneously, and normal internet routing — not DNS — delivers each packet to whichever announcing location is topologically closest. This course covers that routing-level trick in full later on; a CDN using anycast skips the DNS-steering step entirely, since routing alone already sends each client to a nearby edge.

What actually gets cached, and what can't be

Not everything a website serves is equally cacheable. A CDN's edge servers are effective specifically for content that's the same for every visitor and doesn't need to be regenerated per request:

  • Static assets — images, CSS, JavaScript bundles, fonts, videos — are the classic case. They rarely change, they're identical for every visitor, and serving them from a cache instead of the origin is close to free.
  • Whole HTML pages can be cached too, for content that's genuinely the same for everyone: a blog post, a product listing, a documentation page like this one.
  • Personalized or dynamic responses — a logged-in user's account dashboard, a shopping cart, an API response built from a database query specific to that request — generally can't be cached at the edge at all, or only very narrowly, because the whole point of a cache is serving the same stored response to many different requests, and a personalized response by definition isn't the same for anyone else.

A response's own headers are what tell a CDN — and any other cache along the way — whether and for how long it's allowed to store a copy:

Cache-Control: public, max-age=86400

public means any cache, including a shared CDN edge server, may store this response; private would restrict caching to the requesting browser alone, explicitly excluding shared caches like a CDN. max-age=86400 sets how long, in seconds, the cached copy may be served without checking back with the origin — here, 24 hours. Getting this wrong in either direction causes real problems: caching something that shouldn't be shared (leaking one user's personalized content to another) or, more commonly, caching something for far too short a time and sending every request needlessly back to the origin, defeating the entire purpose of having edge servers in the first place.

What happens when the edge doesn't have it yet

The first request for a given piece of content at a given edge server is, by definition, something that edge server has never served before — there's nothing to answer from cache yet. This is a cache miss, and the edge server handles it by fetching the content from the origin server, storing a copy locally, and then serving that copy to the requesting client. Every subsequent request for the same content at that same edge, until the cache entry expires, is a cache hit, answered entirely from the edge without touching the origin at all.

curl -sI https://example.com/logo.png | grep -i "x-cache\|age:"

X-Cache: HIT
Age: 3421

Most CDN providers expose a header like X-Cache (the exact name varies by provider) confirming whether a given response was served from cache or fetched fresh from the origin, and Age reports how many seconds ago the cached copy was originally fetched — both genuinely useful when diagnosing whether a CDN is actually doing its job for a given piece of content, rather than quietly missing on every request and forwarding everything to the origin anyway.

Practical scenario: a CDN that isn't actually reducing origin load

A team enables a CDN in front of their API and expects origin traffic to drop substantially. A week later, origin server load is barely changed, and the CDN provider's dashboard shows a cache hit ratio near zero.

curl -sI https://api.example.com/products/142 | grep -i "cache-control"

Cache-Control: no-store

The origin server is explicitly telling every cache, including the CDN's own edge servers, not to store this response at all. no-store is the strictest caching directive there is — stronger than a short max-age, it forbids caching entirely, for any duration, anywhere. The API was almost certainly built without CDN caching in mind from the start, likely because early responses genuinely were personalized per user and someone reasonably set no-store to avoid leaking one user's data to another — but the specific endpoint in this case, /products/142, returns the same public product data for every caller and never should have inherited that same blanket header.

The fix isn't a CDN configuration change at all — the CDN is behaving exactly as instructed. It's auditing which endpoints actually return identical, shareable responses and giving those a real Cache-Control: public, max-age=... instead of the blanket no-store inherited from endpoints that genuinely need it. A CDN can only cache what the origin explicitly allows it to.

Practice exercises

  1. Run dig <a-well-known-CDN-backed-domain> A from your own connection and note the returned address. If you have access to a VPN or a friend in another country, compare the result — explain what you'd expect to see differently and why.
  2. Explain the difference between Cache-Control: private, max-age=3600 and Cache-Control: public, max-age=3600 in terms of who is and isn't allowed to store a copy of the response.
  3. A cache hit ratio dashboard shows 95% for static assets and 2% for an HTML page that displays the same public content to every visitor. List the two most likely causes and how you'd check each one from the response headers alone.

Reducing distance to the visitor is only one half of what a CDN buys a site — the other half is what happens at the edge server itself once a request arrives, and how a CDN decides when a cached copy has gone stale and needs replacing. Both of those questions get their own dedicated treatment later in this course, in the module covering advanced and real-world topics.

Sources