A global edge network announces the same IP addresses from hundreds of locations. How does traffic reach the right one, what happens when a location fails, and what does this make harder?

How it works

The same address block is announced via BGP from many locations. Each network on the internet independently selects a route to that prefix based on its own routing policy — AS path length, local preference, peering relationships. Traffic follows the route the network considers best, and each client reaches whichever location its network's routing selected.

Note what this is not: it is not latency-based selection. BGP has no concept of latency. The selected path is usually topologically close and therefore usually fast, but "usually" is doing real work in that sentence.

What happens when a location fails

Withdraw the announcement from that location. Networks reconverge, typically within seconds to tens of seconds, and traffic moves to the next-best location automatically. No DNS change, no cache to expire, no client involvement.

This is the decisive advantage over DNS-based failover, where TTLs are honoured inconsistently and a tail of clients continues reaching a dead endpoint for far longer than any configured value.

Failure handling also degrades gracefully in partial cases: a location can withdraw selectively — dropping some peers while keeping others — to shed a portion of its load rather than all of it.

What it makes harder

1. No stateful sessions across locations. Routing can change mid-connection when a network's path selection changes, sending packets to a different location that has no knowledge of the connection. For TCP, that terminates the connection. This is why anycast suits stateless request-response and short connections, and why long-lived stateful sessions need either connection migration support or a unicast address for the session's duration.

2. Load balancing is not controllable directly. Traffic distribution is determined by everyone else's routing policy. A location can receive far more traffic than its capacity because a large network chose it, and the only levers are indirect: announcement adjustments, path prepending, communities. This is genuinely awkward operational work.

3. Debugging is location-dependent. "Users in this network are slow" requires knowing which location they reach, which is a property of their network's routing rather than anything observable from your side without measurement infrastructure.

4. Route leaks and hijacks are a real threat. Another network announcing your prefix attracts your traffic. Mitigations — RPKI, route origin validation, monitoring — are necessary and only partly effective.

5. Capacity planning per location is uncertain, because a routing change elsewhere can shift substantial traffic overnight with no warning.

The design that follows

Anycast for the stateless, latency-sensitive front door: DNS, HTTP request routing, edge cache serving, DDoS absorption. Once a session needs state or a long connection, either terminate the anycast connection at the edge and use unicast internally, or use a transport that survives path changes.

The general shape is: anycast to get the request to a good location; something else to keep it there.