Request Routing: Finding the Nearest Proxy
Why this matters: a CDN with perfect content placement is worthless if clients get sent to the wrong edge. Routing is where the DNS and Load Balancer chapters converge into this design.
Key takeaway
To minimize user-perceived latency, clients should be routed to the nearest proxy server — where "nearest" is a function of network distance and request load, not geography alone.
What "nearest" means
Two factors matter:
| Factor | What it means |
|---|---|
| Network distance | A function of two things: the length of the network path, and the capacity (bandwidth) limits along it. The shortest path with the highest capacity is the nearest proxy — that combination is what lets content download quickly |
| Request load | The load a proxy handles at a point in time. If a set of proxies is overloaded, routing should forward to a less loaded location, balancing load and reducing response latency |
Mechanism 1: DNS redirection
In a typical DNS resolution you get an IP for a name. But DNS can also return another URI instead of an IP — a DNS redirect.
Content providers use it to send a client to a specific CDN. If a client resolves a name containing the word "video", the authoritative DNS server returns another URL — say cdn.xyz.com. The client performs a second DNS resolution, and the CDN's authoritative DNS returns the IP of an appropriate proxy server.
Depending on the user's location, the DNS response can be different — which is what makes this a routing mechanism rather than a lookup.
The two steps
- Map the client to the appropriate network location.
- Distribute load over the proxy servers in that location, balancing among them.
Within each point of presence (PoP) — the London data center, for instance — intra-PoP load balancing decides which proxy handles each request. That keeps traffic evenly distributed locally and maintains availability if one proxy becomes overloaded or unavailable.
To shift a client from one machine to another, DNS replies at the second step carry short TTLs, so the client re-resolves shortly. DNS then keeps delivering content by routing around hardware failures and network congestion — load balancing traffic, using intelligent failover, and maintaining servers across many data centers.
Because proxy load changes over time, the content provider must keep making appropriate changes in DNS for redirection to stay effective. Many CDN providers such as Akamai use DNS redirection.
Mechanism 2: Anycast
Anycast is a routing methodology in which all edge servers in multiple locations share the same single IP address. It uses the Border Gateway Protocol (BGP) to route clients based on the internet's natural network flow, so clients reach the nearest proxy.
The appeal is that the network itself does the routing — there is no DNS TTL to wait out and no cached answer to go stale. Failover is a routing convergence rather than a cache expiry, which makes it dramatically faster than DNS redirection. This is the same mechanism the DNS chapter described behind the 13 root servers.
Mechanism 3: Client multiplexing
The client is sent a list of candidate servers and chooses one to send the request to.
This approach is inefficient, because the client lacks the overall information to choose the most suitable server. It may pick an already-loaded server and experience higher access latency.
The failure is structural: the client cannot see load, health, or network conditions across the fleet. Only the routing system has that view — so putting the decision in the client discards it.
Mechanism 4: HTTP redirection
The simplest of all approaches. The client requests content from the origin server, which responds with an HTTP redirect status code (e.g. 302) and a Location header pointing to the CDN URL. The client follows the redirect and fetches from the CDN.
Client request: GET /logo.svg HTTP/1.1 Host: www.facebook.com Server response: HTTP/1.1 302 Found Location: https://static.xx.fbcdn.net/rsrc.php/y8/r/dF5SId3UHWd.svg
The client automatically follows the redirect and downloads the logo from the CDN.
Simple, and it costs a full round trip to the origin before the client even learns where to go — which is the latency the CDN exists to remove. That makes it a reasonable fallback, not a primary mechanism.
Comparing the four
| Mechanism | Who decides | Speed to converge | Weakness |
|---|---|---|---|
| DNS redirection | CDN's authoritative DNS | Minutes (TTL-bound) | Slow failover; skewed by resolver caching; resolver location ≠ user location |
| Anycast | The network (BGP) | Routing convergence — fast | Less control over the specific target; harder to load-balance precisely |
| Client multiplexing | The client | Immediate | Client lacks the information to choose well |
| HTTP redirection | The origin server | Immediate | Costs a full origin round trip first |
Key takeaway
DNS redirection is the workhorse — coarse, global, and widely deployed. Anycast is faster to converge and gives up fine control. HTTP redirection is simple and pays an origin round trip. Client multiplexing pushes a decision to the party least equipped to make it.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "DNS sends the user to the closest edge server." |
| L5 | Corrects 'closest': "nearest by network distance and load, not geography — DNS maps the client to a location, then a local load balancer picks the proxy." |
| Staff+ | Compares mechanisms: "DNS redirection is standard but TTL-bound and skewed by resolver caching, so failover takes minutes. Anycast lets BGP converge instead, which is far faster but gives up precise load control. I'd use DNS for placement and anycast where fast failover matters." |
Next: keeping the edges from serving stale content.