One name, thousands of doors
In the previous guide you met the content delivery network (CDN): a chain of local warehouses, with edge servers scattered in hundreds of cities so that the content a reader wants is already sitting close by. But that picture leaves one stubborn question unanswered. The reader's browser never types a city or a server number — it types one name, like `cdn.example.com`. So how does that single name turn into the address of the nearest warehouse, out of thousands, in the few milliseconds before a page loads? That act of quietly pointing each visitor at a good door is what this guide is about. Engineers call it request steering.
Why fuss over which door? Because of the lesson from the very first guide in this rung: distance and round trips dominate latency, and no amount of bandwidth beats the speed of light. Sending a reader in Taipei to an edge server in Taipei instead of one in Frankfurt can cut the round-trip time from ~250 ms to a few. Good steering is therefore not a nicety; it is most of what makes a CDN feel fast. The hard part is that the steering decision has to be made before the browser ever connects — it has to be folded into a step that happens earlier, and there are only two places early enough to do it: the name lookup, and the routing of the very first packet.
Steering by name: DNS-based redirection
The first place to steer is the DNS lookup, the Internet's phone book you traced earlier from root to authoritative. The trick is simple and a little sneaky: the CDN runs the authoritative name server for `cdn.example.com` itself, so it is the CDN that decides what address to hand back — and it can hand back a different answer to different askers. When a resolver in Taipei asks for the name, the CDN's name server looks at where that question came from, picks an edge server in or near Taipei, and replies with that edge server's IP address. A resolver in London asking the same name gets a London edge server's address. Same name, different doors, chosen at lookup time.
- The browser asks its resolver for cdn.example.com, just like any name lookup.
- The resolver works down the phone book and reaches the CDN's own authoritative name server for that name.
- That name server looks at who is asking (roughly, the resolver's location) and picks a nearby, healthy edge server.
- It replies with that edge server's IP address — with a deliberately short TTL so the choice can be revised soon.
- The browser connects to that address and fetches the content from a warehouse close by.
Notice the short TTL. Earlier you learned that DNS answers carry a time-to-live so they can be cached, and that a long TTL means fewer lookups. A CDN does the opposite on purpose: it sets a tiny TTL, often a minute or less, so the steering answer expires quickly and the next lookup can be re-routed. If an edge server fills up, has a fault, or a whole region goes dark, the CDN simply starts answering new lookups with a different address, and traffic drains away from the trouble within a TTL or two. The phone book becomes a live steering wheel.
Steering by route: anycast
The second place to steer is even earlier and more radical. With anycast, the CDN gives the same IP address to many edge servers in many cities at once, and lets the Internet's own routing carry each packet to whichever copy is closest. This sounds impossible — surely one address means one place? Recall from the routing rungs how packets find their way: routers do not know about final destinations, they just pass a packet to the next hop along the cheapest advertised route, and address blocks are advertised across the Internet by BGP. Anycast simply has the CDN advertise the same address block from dozens of locations. Each router then naturally forwards toward the nearest one, because that is the route it already considers cheapest.
Anycast: ONE address, advertised from MANY sites
Site A (Taipei) --advertises--> 203.0.113.0/24
Site B (Tokyo) --advertises--> 203.0.113.0/24
Site C (Frankfurt)--advertises--> 203.0.113.0/24
Packet from a reader in Taipei, dest 203.0.113.10:
router picks the cheapest route it knows for 203.0.113.0/24
-> that route leads to Site A (Taipei) <- nearest copy wins
A reader in Germany sending to the SAME 203.0.113.10
-> their routers' cheapest route leads to Site C (Frankfurt)Anycast has two lovely properties. First, the steering is instant and needs no per-request decision: the routing tables, built and maintained by BGP anyway, do all the work. Second, it heals itself. If a site goes offline it simply stops advertising the address; within seconds BGP withdraws that route and every router quietly re-converges on the next-nearest copy. No name needs re-resolving and no client needs telling — the failure is absorbed by the routing fabric itself, which is exactly why anycast is the workhorse for things that must never go down, like the DNS root servers and a CDN's front line.
The honest catch: routing chooses the cheapest path by network topology, not by geography or by milliseconds. The router-cheapest copy is usually the closest, but not always — sometimes a path that looks short in BGP terms is slow in real life. Worse, a TCP connection assumes it is talking to one fixed machine, yet if routes shift mid-connection a packet could suddenly arrive at a different anycast copy that has no idea about this connection, breaking it. That is why anycast is wonderful for short, self-contained exchanges (a single DNS query, the first connection to a CDN) but is paired carefully with other tricks for long-lived TCP sessions. Each steering method has a job it is best at.
Inside one site: load balancing
Steering by name or by route gets a request to the right city. But a busy edge site is not one machine — it is a rack, or rows of racks, of identical servers behind a single public address. Something has to spread the incoming connections across them so no one server drowns while others idle. That something is a load balancer, and it is the receptionist of the data center: every request walks up to one desk, which decides which of the many waiting agents will actually handle it. Without it, the clever steering would just funnel a whole region's traffic onto one poor box.
Load balancers come in two flavours, named for the layer they read. A layer-4 load balancer works at the transport layer: it sees TCP connections — source and destination addresses and port numbers — but does not open the message inside. It just picks a backend server (say, by hashing the connection's four-part identity so the same connection always lands on the same server) and shovels packets between client and that server, fast and cheaply, without ever understanding that this is HTTP at all. It is a receptionist who routes you by the colour of your ticket without reading what is on it.
A layer-7 load balancer works at the application layer: it actually terminates the connection, reads the HTTP request, and can make decisions on its contents. Because it can see the requested path and headers, it can send `/api/...` to the API servers and `/images/...` to the image servers, keep a user's session pinned to one backend, or retry a failed request on a healthy server. This is exactly a reverse proxy from the earlier guide, now doubling as a distributor — it reads what is on your ticket and routes you to the specialist who handles your kind of request. The cost is that opening and understanding every request takes more work than a layer-4 balancer that just shovels packets.
Health checks and putting it together
There is one more piece that makes all of this trustworthy: the load balancer constantly polls its backends with a tiny health check — a quick probe that asks each server are you alive and well? A server that stops answering, or starts returning errors, is pulled out of the rotation within seconds, and new requests flow only to the healthy ones. This is the same reflex as the CDN's short DNS TTL and anycast's route withdrawal, just one layer in: at every scale, good steering means continuously sensing what is broken and quietly routing around it.
Now thread one request through the whole machine. A reader in Taipei opens a video page. Their browser resolves the CDN's name, and either DNS-based redirection hands back a Taipei edge address, or the name resolves to an anycast address whose route already leads to the Taipei site — both end the same way, at a nearby front door. At that door a layer-4 load balancer spreads the new connection across a row of layer-7 balancers; one of those reads the HTTP request, sees it wants a video segment, and dispatches it to a server holding that content. Three steering decisions, at three different layers, all aimed at the same goal you started this rung with: cut the distance, cut the round trips.
Keep one honest boundary in view. All this steering shortens distance and balances load, but it does not, by itself, secure anything: a layer-7 balancer that terminates the TCP connection reads your request in the clear unless TLS wraps it, and pointing you at a nearby server says nothing about whether that server is honest. Steering is about speed and resilience, not trust — the security guides in the next rung pick up that separate thread.