Anycast is the trick underneath half the modern edge: announce identical IP space from many locations and let internet routing deliver each user to one of them. It is elegant, it is everywhere, and its behavior under stress is exactly as political as BGP itself.
How the steering actually works
Each POP announces the same prefixes to its transit and peering partners; every router on the internet picks its preferred path per standard BGP selection, shortest AS path and local policy first. Users land wherever their provider’s routing table points, which correlates with, but does not equal, geographic proximity. Operators shape the outcome with selective announcements, path prepending and community tags, but the last word always belongs to other people’s routers, which is anycast’s essential bargain.
The failure and shift behaviors
Withdraw a POP’s announcement and the internet reconverges around it in seconds to minutes: failover without DNS TTLs, one of anycast’s genuine superpowers. The shadow side: routing changes anywhere can silently shift user populations between POPs mid-session. For stateless HTTP this is invisible; for long-lived TCP flows a route flap means connection resets, which is precisely the problem QUIC connection IDs and connection-aware load balancing inside the edge were built to absorb.
The DNS-mapping comparison rounds this out, because the industry’s two routing religions fail oppositely. Anycast’s placement is decided by routers you do not control, per packet, with instant failover and occasional mid-session shifts. DNS mapping’s placement is decided by the provider’s brain, per resolution, with fine control and failover bounded by TTLs and resolver behavior. Hybrids increasingly hedge: anycast front doors with DNS-steered overlays, or anycast within regions and mapping between them. When a vendor explains their routing, ask which decisions happen at which layer and on what timescale; the architecture answer predicts their failure modes better than their uptime slide.
Catchment engineering
The distribution of users to POPs, each site’s catchment, is an engineering artifact: peering breadth, announcement scope and traffic engineering decide whether Jakarta users land in Jakarta or Singapore. Providers measure and tune this constantly; buyers can verify it trivially, most edges expose a header or debug endpoint naming the serving POP, and mapping real-user requests to serving sites reveals catchment quality faster than any sales map.
In practice
Two verifications worth an afternoon: sample which POPs actually serve your top user geographies (headers plus RUM beacons), and quantify long-flow stability if you ship large downloads or live streams over TCP. Catchment misses and flap-induced resets are both fixable conversations with a provider, but only if you arrive with the measurements, because their dashboards are aggregated across everyone and yours are not.
Our provider dossiers include catchment maps measured from real user populations, not press-release POP counts.