Skip to content

Introduction to CDN internals

The CDN article earlier in this course covered the part visible from outside: DNS or anycast routes a visitor to a nearby edge server, that server answers from cache when it can, and Cache-Control headers decide what's allowed to be cached at all. What it deliberately left for later is everything that happens inside one of those edge servers — what a point of presence actually is as a piece of infrastructure, what happens the moment a request lands on it, and how dozens or hundreds of these locations end up behaving like one consistent service instead of hundreds of independent, occasionally-contradicting caches.

A point of presence is a small reverse-proxy fleet, not one machine

"Edge server" makes a point of presence (PoP) sound like a single box sitting in a data center somewhere near the visitor. In practice, a PoP is itself a small fleet — often dozens to hundreds of physical machines in one facility, each running the same caching software, sitting behind the CDN provider's own internal load balancer. When your DNS lookup or your anycast route lands you on 184.31.5.10 in, say, an Almaty PoP, that IP address doesn't identify one physical server; it identifies the PoP's own front door, which then picks whichever internal machine actually handles your request.

Functionally, what runs on each of those machines is a caching reverse proxy — the same architectural role the reverse proxy article already introduced, with a cache layered on top. Every property that made a reverse proxy invisible to the client still applies here: your browser believes it's talking to cdn.example.com directly, has no way to see that a proxy intercepted the connection, and gets a response that's supposed to be indistinguishable from one the origin server produced itself.

Browser ──▶ PoP's anycast/DNS-assigned IP ──▶ internal load balancer ──▶ one cache node ──▶ (cache hit or fetch from origin)

What happens inside one PoP when a request lands

Picture a request for /logo.png arriving at a cache node that has genuinely never seen it before. The sequence is a straightforward pipeline, but each stage does real work worth naming:

  1. Cache key computation. The node needs a single string to look this response up by and store it under later. By default that's usually the request's method, host, and path — but a misconfigured or overly narrow cache key is one of the most common sources of CDN bugs in practice, and it gets a full treatment in the next article.
  2. Cache lookup. The node checks whether it already holds a fresh, unexpired copy stored under that key. On a miss, it moves to step 3; a hit skips straight to step 5.
  3. Origin fetch. The node opens (or reuses) a connection to the origin server, forwards the request essentially unchanged, and waits for the response — this leg of the trip is what Edge and origin servers covers in depth.
  4. Store, honoring the origin's caching headers. If the origin's Cache-Control allows it, the node stores the response under the cache key from step 1, along with however long it's allowed to be considered fresh.
  5. Serve. The response — whether it came straight from cache or was just fetched and stored — goes back to the client, usually with a header disclosing which of those two things just happened.
curl -sI https://example.com/logo.png | grep -i "x-cache"

X-Cache: MISS

The earlier CDN article already showed this exact header confirming a hit; a miss looks identical except for the value, and it means exactly what step 3 above describes — this specific node, for this specific cache key, had nothing stored and had to go fetch it.

Hundreds of independent caches, one apparent service

Here's the part that isn't obvious from the outside: every PoP, and often every individual cache node within a PoP, maintains its own separate cache. There's no single shared cache spanning a CDN provider's entire network. A MISS in Almaty tells you nothing about whether Frankfurt or Tokyo already has that same object cached — each of them only knows what's landed on it before, from the traffic that happened to route through it.

This has a very concrete, very common consequence: the very first visitor to reach any given PoP for a piece of content pays the full origin round trip, even if a million other visitors around the world have already triggered a cache fill in every other PoP. A launch-day traffic spike distributed evenly across a CDN's PoPs looks, from the origin's point of view, like a wave of near-simultaneous first-time cache misses — one per PoP, not one total — which is exactly why a sudden regional traffic spike can still produce a real, sometimes surprising burst of origin load even with a CDN correctly configured in front of it.

Note

A CDN gives you geographic distribution, not one global cache. Every PoP starts cold for any given object, and stays independently responsible for keeping its own copy fresh — a distinction that matters the moment you're debugging why one region is serving stale content while another already shows the update.

Practical scenario: a purge that "didn't work" in half the world

A team pushes an urgent content fix, issues a cache purge through their CDN provider's dashboard for the affected URL, and confirms the fix is live by checking from their own office. Support tickets start arriving an hour later from users in another region still seeing the old content.

curl -sI https://example.com/pricing | grep -i "x-cache\|x-served-by"

X-Cache: HIT
X-Served-By: cache-nrt-1234

cache-nrt-1234 names a Tokyo-area cache node, and the HIT confirms it's serving a stored copy rather than fetching fresh — meaning this particular node never received or hadn't yet processed the purge request. Most CDN providers propagate a purge across every PoP asynchronously, and while that propagation is typically fast, "fast" is not "instant" or "guaranteed to land everywhere in the same second." A team that checks only from one location right after issuing a purge, sees the new content, and declares the incident closed has verified exactly one PoP out of however many the provider operates.

The fix here isn't a CDN misconfiguration — it's a process gap. Checking a purge's completion needs either the provider's own purge-status API (most CDNs expose one specifically because "did it actually finish everywhere" is a genuinely common question) or a multi-region check using a tool that queries from several geographic vantage points, rather than trusting a single request from the team's own office. The mechanics of purging itself, and the alternatives to a blunt full purge, are what the next two articles in this sub-module cover.

Practice exercises

  1. Two visitors in different cities request the same URL for the first time within a second of each other, and each is routed by anycast to a different PoP. Explain, using the "cold by default" property above, whether both requests hit the origin, and why.
  2. A monitoring dashboard shows a CDN's overall cache hit ratio suddenly dropping during a regional flash sale, even though the sale page's Cache-Control headers haven't changed. Using the PoP-independence property above, suggest one plausible explanation that has nothing to do with the caching headers being wrong.
  3. Using the request pipeline above, name which specific step is responsible for deciding whether a response gets stored at all, and which step decides where it gets stored under.

Every step in this pipeline assumes the fetch from origin, when it happens, actually succeeds cleanly and quickly. That assumption is exactly what the relationship between an edge node and its origin server is built to protect — and what happens when that relationship is designed carelessly is a common, painful source of origin outages that a CDN was supposed to prevent in the first place.

Sources