Anycast Routing: One Address, Everywhere at Once
Series: System Design · Networking & Protocols — Pillar 2 of 8
Anycast Routing: One Address, Everywhere at Once
Systems Design
| # | Post | What it covers |
|---|---|---|
| 00 | Networking & Protocols: How Bytes Actually Travel | Before you can design systems that scale, you need to understand how bytes actually travel. Eight concepts every backend engineer must know. (148 chars) |
| 01 | The OSI Model: The Map Every Engineer Needs | The OSI model isn't just interview theory — it's the map that tells you exactly where in the stack a network problem lives. Here's how to use it. (152 chars) |
| 02 | TCP vs UDP: Reliability vs Speed at the Transport Layer | TCP guarantees delivery. UDP doesn't look back. Understanding why each exists — and when to reach for each — is fundamental to network design. (150 chars) |
| 03 | HTTP vs HTTPS: The Language of the Web and Its Secure Version | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 04 | TLS/SSL: How HTTPS Actually Works Under the Hood | TLS is what puts the S in HTTPS. Here's how the handshake works, what a certificate actually contains, and why TLS 1.3 matters for performance. (152 chars) |
| 05 | DNS: The Phone Book That Runs the Internet | DNS is the phone book of the internet — and one of the most misunderstood layers in the stack. Here's how it works and how it fails. (133 chars) |
| 06 | DNS Load Balancing: Traffic Distribution at the Name Layer | DNS load balancing distributes traffic before a single packet reaches your servers. Here's how it works, where it excels, and where it falls short. (154 chars) |
| 07 | Anycast Routing: One Address, Everywhere at Once ← you are here | One IP address, dozens of locations, zero client configuration. Anycast is how the fastest global infrastructure works — here's the mechanism behind it. (158 chars) |
| 08 | CDN: Moving Content Closer to the People Who Need It | A CDN isn't just a cache in front of your server. Here's how content delivery networks work, when they help, and when they add complexity for nothing. (154 chars) |
| 09 | Networking & Protocols: Wrap-Up | A complete recap of the eight core networking concepts — OSI, TCP, HTTP, TLS, DNS, CDN — and how they connect into a complete picture. (135 chars) |
Anycast is uniquely suited to services where:
Every client wants the same thing (a DNS response, a static asset, a TLS handshake)
Proximity to the client matters for latency
High availability across locations is required
Where Anycast is used in production
DNS resolvers
The most visible Anycast deployments are public DNS resolvers. 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9) are all Anycast addresses, served from hundreds of locations globally. This is what makes them fast everywhere — not caching alone, but physical proximity to the user achieved through Anycast routing.
The 13 root DNS nameservers are also Anycast — each logical root server is actually hundreds of physical instances. There are over 1,500 root server instances globally, all reachable via Anycast under 13 IP addresses.
CDN edge nodes
CDNs use Anycast to route users to the nearest edge node. When your browser connects to a Cloudflare-protected site, it connects to Cloudflare's Anycast IP range. BGP routes that connection to the nearest Cloudflare PoP (Point of Presence) — which may be in the same city. The TLS handshake, HTTP request, and cache lookup all happen locally, with only a cache miss requiring a trip to the origin server.
DDoS mitigation
Anycast is a powerful tool for absorbing distributed denial-of-service attacks. When attack traffic is distributed across hundreds of Anycast nodes globally, the volume any single location must absorb is a fraction of the total. Cloudflare, Akamai, and AWS Shield all use Anycast as a core component of their DDoS mitigation architecture.
Without Anycast, a DDoS attack concentrates at a single IP — one location must absorb the full volume. With Anycast, the attack traffic is automatically distributed across the global network, which collectively has the capacity to absorb volumes that would overwhelm any single location.
In the URL shortener
At scale, our URL shortener would benefit from Anycast at the CDN layer: users anywhere in the world connect to the nearest CDN edge node (via Anycast), which handles the TLS handshake locally and serves cached redirects from edge cache. Only uncached short codes require a request back to the origin. The combination of Anycast routing and CDN edge caching is what makes globally fast redirect latency achievable without running application servers in every region.
The tradeoffs
Anycast and TCP stateful connections. Anycast works perfectly for stateless protocols — DNS queries, cached HTTP responses, individual UDP packets. It creates a problem for long-lived TCP connections: if a BGP route change reroutes packets mid-connection to a different Anycast node, the new node has no knowledge of the TCP session state and the connection drops.
For this reason, Anycast is most commonly used for:
UDP protocols (DNS queries are typically UDP)
Short-lived TCP connections (a single HTTPS request to a CDN edge)
TLS termination at the edge, with a persistent backend connection to origin
It's not suited for long-lived stateful TCP connections where mid-connection rerouting would be disruptive — database connections, WebSocket sessions, streaming protocols.
BGP convergence isn't instant. Anycast failover is faster than DNS failover, but BGP convergence takes 30–90 seconds — not milliseconds. During convergence, some traffic may be transiently routed to unreachable or overloaded nodes. For most use cases this is acceptable; for applications requiring zero disruption, it's a constraint to plan around.
Operational complexity. Running an Anycast deployment means operating BGP infrastructure — announcing prefixes to upstream providers, managing route policies, monitoring for route leaks. This is genuinely complex infrastructure work. For most teams, the right answer is to use a CDN or managed DNS provider's Anycast infrastructure rather than building their own. The operational complexity is real and the expertise required is specialised.
You can't Anycast without your own IP space. Anycast requires announcing the same IP prefix from multiple autonomous systems. This requires owning a Provider-Independent (PI) IP address block — not using IPs assigned by your hosting provider, which are tied to their BGP announcements. Most application teams never deal with this directly because they're consuming Anycast through CDN or DNS providers.
Anycast vs GeoDNS
Both achieve geographic traffic distribution. They operate differently and have different characteristics:
| Anycast | GeoDNS | |
|---|---|---|
| Mechanism | BGP routing at the network layer | DNS responses varied by resolver location |
| Client sees | One IP address | Different IPs for different locations |
| Failover speed | Seconds (BGP convergence) | Minutes (TTL + health check interval) |
| Session continuity | Disrupted if route changes | Stable for cached TTL duration |
| Suitable for | UDP, short-lived TCP, DDoS mitigation | Long-lived connections, stateful services |
| Operational complexity | High (BGP infrastructure) | Low (DNS provider configuration) |
In a complete architecture they complement each other: GeoDNS routes clients to the right Anycast cluster; Anycast routes within that cluster to the nearest node.
The one thing to remember
Anycast makes one IP address physically close to every client simultaneously — not through client configuration or DNS indirection, but by letting the internet's routing infrastructure do the work. It's the technique behind every "how is this so fast everywhere?" global service. For most teams, the right way to leverage Anycast is through a CDN or managed DNS provider that already operates the BGP infrastructure — not by building it yourself. But understanding how it works explains a class of global infrastructure performance that would otherwise seem like magic.
← Previous: DNS Load Balancing — DNS resolves names to IPs. The next post covers how to use that resolution step itself as a traffic distribution mechanism — and where it works brilliantly and where it falls short.
→ Next: CDN — Anycast gets users to the nearest edge node fast. CDNs are what those edge nodes actually do: cache content, terminate TLS, absorb traffic, and make global performance possible without running origin servers everywhere.
