How CDNs Decide Where to Serve a Request

A CDN does not look up the user on a map and pick the nearest building. Two different decisions happen, and they are easy to mix up. DNS (or Anycast routing) chooses which edge location receives the connection. The software on that edge then chooses whether to answer from cache, run edge code, or fetch from origin.

This piece stays on those two decisions and only uses behavior that public documentation describes. A longer, more speculative pass at the same topic lives in the CDN routing architecture teardown. Vendor-specific Akamai routing is covered separately in How Akamai routes a CDN request.

How a request reaches an edge

The client almost never talks to origin first. A typical path, documented in Cloudflare's overview of how the network sits in front of an origin, looks like this:

1. The browser asks a recursive resolver for the hostname.
2. The resolver asks the CDN's authoritative DNS.
3. The answer is an IP address (or a CNAME that eventually becomes one).
4. The browser opens TCP and TLS to that address.
5. Whichever edge receives the packets handles the HTTP request.

That last step is the part people flatten into "the nearest building." It is not one mechanism. CDNs use at least two, and they answer different questions.

Anycast and GeoDNS decide different things

Anycast advertises the same IP prefix from many locations. Routers forward the packet along a BGP path. RFC 4786 describes how anycast services work: the selected site is a function of routing, not of geographic distance. Cloudflare's troubleshooting note on geographic traffic routing says the same thing in product language: traffic does not always land in the geographically closest data center, because ISP peering and BGP policy choose the path.

GeoDNS (and latency-based DNS) is a different lever. The authoritative server returns different addresses based on the resolver it sees, or on measurements tied to that resolver. Cloudflare's traffic steering docs describe steering modes such as geo and dynamic latency as explicit load-balancing choices. Those modes see the resolver's network, which is not always the user's network. A laptop in one city using a public resolver in another city can be steered toward the resolver, not the laptop.

Neither mode guarantees the lowest round-trip time. Anycast follows routing policy. GeoDNS follows the signal the DNS layer was given. Both can be wrong for a user whose path is congested or whose resolver is far away.

Why nearest is not the same as fastest

Cloudflare's geographic-routing note is the clean public statement of the failure mode: a user can be closer on a map to data center A and still be routed to data center B because their ISP's path prefers B. Common reasons, all visible in public routing and CDN docs rather than in a vendor's private health database:

• The user's ISP peers with the CDN in a different city.
• BGP prefers a path with more capacity over a shorter geographic path.
• The resolver used for DNS is not in the user's city, so GeoDNS optimizes for the resolver.
• A site is withdrawn from routing while DNS still has an older answer, until the DNS TTL expires.

Round-robin DNS is a weaker version of the same mistake. It cycles through a fixed list of addresses and has no view of path quality or whether a site is reachable. It can still be a fine choice for a handful of origins behind one region. It is a poor model of how a global CDN picks an edge.

What the edge does after the connection lands

Once packets arrive, the edge is no longer choosing a city. It is choosing a response. Public CDN descriptions agree on the shapes, not on a single universal order:

• A cache lookup can answer without contacting origin. Cloudflare's CDN reference architecture describes caching at the edge as the core of the CDN product.
• A cache miss is fetched from origin, or from another cache tier when that product is turned on. Cloudflare documents tiered cache as an optional feature that reduces origin load by fetching through an upper tier. It is not a hidden default inside every CDN.
• Edge compute (Cloudflare Workers, CloudFront Functions, Fastly Compute, and others) can run before, around, or instead of a cache read. The order is a configuration choice. Treating "TLS, then WAF, then cache, then Worker, then origin" as the sequence every CDN uses overstates one vendor's request pipeline.

That sequence is a generic cache-aside sketch. It matches the public "hit or go to origin" story. It does not describe TTLs, probe intervals, or a shared health key-value store. Those internals are not in the sources above, so they are not stated here as facts.

Cache behavior that is documented is ordinary HTTP caching: Cache-Control, freshness, and revalidation. Exact eviction size and hit rate are per configuration and are not a single industry number.

When an edge location fails

Failure handling is also split across the two layers.

Routing withdrawal. If a site stops announcing an anycast prefix, new packets follow another BGP path. RFC 4786 treats this as routing convergence, not as an instant geographic handoff. How long that takes depends on the routers involved. Public docs do not publish one universal "rerouted within N seconds" figure, so this article does not invent one.

DNS TTL. If the authoritative server stops returning an unhealthy address, resolvers can keep the old answer until the TTL they cached runs out. A short TTL makes failover faster and increases DNS query load. A long TTL does the opposite. The TTL is a setting, not a law of CDN physics.

Health checks exist as a product (Cloudflare load balancers probe pools and steer away from unhealthy origins). That is origin or pool health inside a load-balancing config. It is not evidence that every CDN runs one global health table that redirects a user to a "sibling PoP" on a fixed timer.

A practical check

You can see which location answered without trusting a blog diagram. Response headers are vendor-specific; read them as hints, not as a standard.

curl -sI https://example.com | grep -iE 'cf-ray|x-cache|x-served-by|x-amz-cf-pop|age|server'

• Cloudflare's cf-ray ends in a colo code for the data center that handled the request. That code is the location that received the request, which may not be the one closest to you on a map.
• Fastly responses often include x-served-by and x-cache (HIT or MISS).
• CloudFront can send x-amz-cf-pop and x-cache.

Run the same request from another network (a phone on cellular versus an office resolver, or a VM in another region) and compare the colo or PoP token. A different token means a different edge received the connection. A HIT means that edge answered from its cache. Neither result measures "the CDN's global health KV."

What is safe to copy

For a small service that is not a CDN:

• Put a cache in front of origin and honor HTTP caching headers. That is the part of the CDN story with the clearest public contract.
• If you run more than one region, pick an explicit steering method (GeoDNS, latency DNS, or anycast) and write down what signal it actually sees.
• Do not assume BGP will send users to the site nearest them. Test with curl from the networks you care about.
• Keep DNS TTLs short only where you need faster failover, and accept the extra lookup traffic.

Skip invented probe intervals, private backbone hop counts, and a single request pipeline that every vendor supposedly shares. Those details need a primary source. The public sources below support the routing split and the cache-or-origin choice. They do not support a universal internal design.

Sources

• RFC 4786: Operation of Anycast Services — anycast selection follows routing, not geography.
• Cloudflare: Geographic traffic routing — traffic is not always sent to the geographically closest data center.
• Cloudflare CDN reference architecture — edge caching as the CDN product.
• Cloudflare: How Cloudflare works — DNS resolution in front of the network.
• Cloudflare traffic steering — geo and latency steering are explicit modes, based on the resolver path.
• Cloudflare tiered cache — upper-tier cache is optional and Cloudflare-specific.
• Amazon CloudFront: how it works — a second vendor's public request path, for contrast.