Anycast routing

Why it matters

DNS-based balancing is slow and approximate because it depends on caches honouring TTLs. Anycast sidesteps the problem: the same address is served from dozens of locations, and the network itself routes each client to the closest one. When a location fails, routing converges around it in seconds without any client or resolver doing anything. It is how the DNS root servers, every major CDN and the large public resolvers (1.1.1.1, 8.8.8.8) achieve global presence with a single address.

The idea

Normally an IP address is unicast: it identifies one place. With anycast, the same address is announced via BGPBorder Gateway Protocol: the routing protocol by which networks announce which address ranges they can reach, and choose paths between them. from many points of presence. Routers pick the shortest path they know, so a client's packets flow to the topologically nearest announcement. Each location runs identical services on that address.

What it buys

• Latency without DNS tricks: clients reach a nearby location by the physics of routing, not by a resolver's guess.
• Failover in seconds: a failed location stops announcing (or is withdrawn by health checks) and routing converges; no TTL involved.
• DDoS absorption: attack traffic is spread across every location rather than concentrating on one, which is the main reason CDNs and DNS providers run anycast.
• One address to publish: useful for resolvers, root servers and anything baked into client configuration.

Where it is awkward

Routing can change mid-connection: a path flaps, a location is withdrawn, and the client's next packet lands at a different location that has no state for that TCP connection, which resets it. For short exchanges (a DNS query, a TLS handshake plus one HTTP request) this is rare and harmless. For long-lived sessions (a two-hour video stream, a WebSocket) it is a real problem, mitigated by keeping sessions short, by synchronising state across locations, or by using anycast only for the first hop and handing the client a unicast address for the session. Running anycast also requires your own address space and BGP presence, or a provider that does it for you.

	DNS-based global balancing	Anycast
Decision made by	Authoritative DNS, per resolver	Network routing, per packet
Granularity	Coarse: one answer steers a whole resolver's users	Fine: each client follows its own shortest path
Failover time	TTL plus cache behaviour, minutes	BGP convergence, seconds
Long sessions	Stable once connected	Can reset on route change
Operational need	A DNS provider with policies	Address space, BGP announcements, or a provider offering anycast
Typical users	Multi-region applications	CDNs, DNS, DDoS scrubbing, global API edges

In practice the two combine: a CDN edge is anycast; the origin behind it is selected by DNS or by the CDN's own routing; the application's load balancers are plain unicast.

Trade-offs

Anycast gives the fastest, most robust global entry point available and costs operational sophistication, address space and care with stateful protocols. It also makes debugging harder: "which server did this request hit" depends on where the client was and what routing looked like at that second. Most teams consume anycast through a CDN or cloud global load balancer rather than running it; knowing that is the point.

In an interview

Reach for anycast when the interviewer pushes on global latency or DDoS: "The edge is anycast through the CDN, so users land at the nearest point of presence and a failed site falls out of routing in seconds. Behind that, regional origins are unicast behind their own balancers." If long-lived connections are part of the design, mention the route-change reset and how you avoid it. That is the full senior answer in three sentences.