Global Load Balancing: GeoDNS & Anycast

Last lesson we worked hard to keep one region's pool of servers healthy — probes, ejection, failover, the works. And it was all in service of a promise we can't actually keep for everyone: fast responses. Because there's a limit no amount of server tuning can beat, and it isn't your CPU. It's physics.

Light in fiber travels about 200,000 km/s — roughly two-thirds of light in a vacuum. A user in Mumbai talking to a datacenter in Northern Virginia is sending signals across about 13,000 km each way. Do the arithmetic and the round trip is at least ~130 milliseconds before a single line of your code runs — and in practice, with real-world routing, it's often 200ms and up. Your servers could answer in zero time and that user would still feel a lag, because the request spent a fifth of a second just traveling. You cannot optimize your way out of the speed of light.

So the only fix is geographic: don't make everyone come to Virginia. Run datacenters — regions — on multiple continents, and send each user to the one nearest them. That's Global Server Load Balancing (GSLB), and here's the thing that makes it interesting: the decision of which region has to be made before the request reaches any datacenter at all. There are exactly two moments where you can make it, and they give us the two mechanisms this whole lesson is about: GeoDNS and Anycast.

It's worth being precise about how this differs from every load balancer we've built so far, because the mental picture is genuinely different.

A normal load balancer picks a server inside one datacenter. All its choices live in the same building; the boxes are a fraction of a millisecond apart; the balancer sits in the request path and reads the request before deciding. Cheap, fast, local.

Global load balancing picks a region across the planet. The choices are thousands of kilometers and tens-to-hundreds of milliseconds apart, and — critically — there's no box sitting in the path yet to make the call. The user just has a domain name and a desire to connect. So the "which region" decision has to be smuggled into the earliest part of getting there:

• Either it happens when the user resolves the name — the DNS lookup hands back a region-specific address. That's GeoDNS.
• Or it happens when the user's packets are routed — one address that the internet itself steers to the nearest location. That's Anycast.

That's the entire framing. One decides at the name; the other decides in the network. Everything else — the policies, the failover speed, the gotchas — falls out of which moment you chose. Let's take them one at a time.

Start with the more intuitive one. Every request begins with a DNS lookup — the browser asks "what's the IP for api.app.com?" GeoDNS hijacks that answer. Instead of every user getting the same IP, the authoritative DNS server looks at where the query came from and hands back a different IP per region: your Mumbai users resolve api.app.com to the Singapore region's address, your Frankfurt users to the EU region's, your Virginia users to us-east's. The routing decision is the DNS response.

This is a real, heavily-used product, not a hack — AWS Route 53, NS1, Cloudflare, Akamai all do it. The elegance is that it needs no special network and no box in the path: DNS was already going to happen, so you just make it smart. The user's device caches the returned IP and connects directly to the nearby region, none the wiser that someone on another continent got a completely different address for the same name.

And because the decision lives in software at resolution time, you get something anycast can't easily give you: fine-grained control over the policy. You don't just get "nearest" — you get to choose what "best" means.

"Send the user to the nearest region" sounds like one rule, but it's actually a menu — and picking the right policy is a design decision, not a default:

• Geolocation routing — deterministic by the user's country or continent. A user in Germany always gets the EU endpoint, even if the US endpoint happens to be faster this second. That determinism is the point: it's how you honor data-residency laws, regulatory compliance, content localization, and licensing ("EU citizens' data stays in the EU," "this video is only licensed in Japan").
• Latency-based routing — route to whichever region has the lowest measured latency for that user, right now. This is the performance-first choice, and it can disagree with geography (a user near a border might be routed to a "farther" region that's actually faster over the current network).
• Weighted (split traffic 90/10 for a canary), failover (primary region, fall back to secondary), and geoproximity (nearest, but with a bias dial to shift load) round out the set.

One sharp edge worth knowing: if you set up geolocation for specific countries and a user queries from one you didn't list, the DNS server returns NXDOMAIN — a hard "no such name." Always configure a default catch-all record so nobody falls through the map. Control is powerful, but control means you're now responsible for covering the whole planet.

GeoDNS has two weaknesses, and both come from the same root: DNS was never designed to know who the user is or to change its mind quickly.

Crack one — it sees the resolver, not you. GeoDNS decides based on the IP of the DNS resolver that asked, not your actual device. Usually those are close together. But a Mumbai user configured to use Google's 8.8.8.8, or anyone on a VPN that exits in another country, looks like they're wherever the resolver is — so your Mumbai user gets routed to the US. The fix is EDNS Client Subnet (ECS): cooperating resolvers (Google, Cloudflare, OpenDNS) forward a slice of the client's subnet to your authoritative server, so it can see roughly where the real user is. It helps, but it's an optional courtesy, not a guarantee.

Crack two — the cache sticks, so failover is slow. This is the big one, and it's the whole reason anycast exists as an alternative. DNS answers are cached — by the OS, the browser, and the resolver — for the length of the TTL you set. That's great for load (fewer lookups) and terrible for failure: when a region dies, every client that already cached its IP keeps dialing the dead address until its cache expires. You can lower the TTL (30–60 seconds is typical for failover records), but here's the ugly truth — resolvers and clients routinely ignore low TTLs and hold onto answers longer to save themselves work. So your real-world DNS failover isn't "30 seconds," it's "30 seconds for the well-behaved clients and minutes for the rest." GeoDNS failover is only as fast as the slowest cache — and you don't control the caches. Hold that thought, because it's exactly what the other mechanism fixes.

This is a lesson about where and how fast, and both of those are things you have to watch on a map, not read in a paragraph. So below is a live world with regions on several continents and users firing requests at the nearest healthy one. You run it.

Drop a user anywhere by clicking the map, and watch their request fly to the closest region — the farther it travels, the more latency it pays, drawn right on the packet. Now flip the balancer between GeoDNS and Anycast and, at first, notice they look the same — both send each user to their nearest region. The difference is invisible until something breaks.

So break it: kill a region. On Anycast, every user headed there reroutes to the next-nearest one instantly — the route is simply withdrawn from the network. On GeoDNS, the users who already cached the dead region's IP keep hammering it, failing, while a TTL countdown ticks down over their heads; only when it hits zero do they re-resolve and recover. That gap — instant versus wait-out-the-cache — is the whole trade-off, and you can watch it happen. (Flip the resolver location too, to catch a user getting mis-routed to the wrong continent because DNS saw their resolver, not them.)

Now the other moment. What if you never made the user's DNS answer choose a region at all — what if every user got the same IP, and the internet itself delivered them to the nearest datacenter?

That's Anycast, and we built its machinery back in the networking chapter, so here we just need its shape and its role. You announce the same IP address from every region using BGP — the internet's routing protocol — and because many places are all shouting "you can reach this IP through me," each router along the way forwards packets toward whichever announcement is nearest by BGP's path metric. A user in Tokyo and a user in London type the same address and get carried to completely different datacenters, entirely by how the network routes. The routing is the load balancer — there's no DNS policy, no box in the path, no decision your software makes at all.

(If you want the full picture of how BGP picks the nearest announcement and why the same IP can live in a hundred places at once, that's the "Anycast: One IP, Many Places" lesson in the networking chapter. Here, what matters is why you'd reach for it over GeoDNS — and that comes down to one dramatic difference.)

Here's the punchline, and it's the reason anycast fronts nearly every global entry point on the internet.

Remember GeoDNS's fatal flaw: when a region dies, you're stuck waiting for a million independent DNS caches to expire, and you don't control any of them. Anycast simply doesn't have caches to wait out. When an anycast region fails, it withdraws its BGP route — it stops announcing "reach this IP through me." Within a BGP reconvergence, which is seconds, every router on the path recalculates and starts steering those packets to the next-nearest announcement. Automatically. No client re-resolves anything. No TTL ticks down. The user's packets were already flowing to "the nearest place that answers this IP," and now the nearest place that answers is somewhere else. Failover happens inside the network, not inside a million caches.

That's the whole appeal: seconds instead of minutes, and zero cooperation required from clients. It's why the DNS root servers, Cloudflare's edge, Google's public DNS, and every serious DDoS-scrubbing front-end run on anycast. But it isn't free, and the costs are the mirror image of its strengths — which is the actual decision you have to make.

Line them up and the choice is really about where the decision lives — and everything else follows from that:

	GeoDNS	Anycast
Decision made	at the DNS answer (name → region IP)	in the network (one IP, BGP picks)
Control	high — geo, latency, weighted, compliance	low — BGP chooses, you don't
Failover speed	TTL-bound — 30s to minutes; caches lag	BGP reconvergence — seconds, no cache
"Nearest" accuracy	the resolver's location (ECS helps)	BGP's AS-path (not always lowest latency)
Long connections	fine — the IP is stable per client	risky — a reconvergence can flip a live TCP mid-stream
Best for	data-residency, compliance, explicit control, stateful regions	global entry points, DDoS soak, stateless/short

Read the last two rows together and the personalities are clear. GeoDNS is the control freak: it'll honor your compliance rules and never move a connection out from under you, but it fails over at the mercy of caches. Anycast is the reflex: it fails over in seconds and soaks up DDoS by spreading one IP across the globe, but it routes by BGP's opinion of "near" and can yank a long TCP connection to a new PoP mid-flow (which is why it's happiest in front of short, stateless things — DNS, UDP, a TLS-terminating edge that just re-establishes). The honest answer to "which one?" is almost never one of them.

The reason "which one?" is the wrong question is that real global systems use both, stacked — each doing the job it's good at.

The production shape looks like this: anycast at the very edge — the CDN and DNS layer — so that the first hop is instant, globally reachable, and DDoS-resistant. Then, once traffic has landed at a nearby edge, GeoDNS or latency-based routing at the origin/app tier to steer it to the right backend region with all the control and compliance policy you need. A single request might ride an anycast IP to reach a nearby DNS resolver, get a GeoDNS answer pointing at the nearest healthy region, and then hit an anycast CDN edge that proxies to the nearest healthy origin. Three routing decisions, two mechanisms, each where it's strongest.

This is exactly how Cloudflare, Google, and AWS actually run. You get anycast's instant failover and DDoS absorption at the edge and GeoDNS's fine-grained, compliance-aware control at the origin. The mechanisms aren't competitors fighting for the same job; they're a fast, blunt outer layer and a smart, precise inner one — the same "fast-then-smart" pattern we saw with L4 in front of L7, now stretched across the whole planet.

Everything from the last lesson still applies here — it just operates on regions instead of servers, and this is where the two mechanisms' failover speeds stop being trivia and start being the whole point.

Global load balancers health-check each region the same way a local balancer checks each box: is the region up, is it serving, is its latency sane? When a region fails the check, it comes out of the global rotation — but how it comes out depends on your mechanism. GeoDNS stops returning the dead region's IP in new answers… and then you wait for the caches, exactly as we saw. Anycast withdraws the region's route and the network reroutes in seconds. Same "route only to the healthy roster" principle as before — the roster is now a handful of continents — and the failover-speed gap is precisely why anycast guards the entry points where seconds of downtime cost the most.

One caution that trips up a lot of designs, though: global load balancing only removes the single-region failure if your data is actually multi-region. It's easy to route a user beautifully to a healthy nearby app region and then have that region reach across the ocean to the one primary database in Virginia — at which point you've paid for global infrastructure to deliver a globally-slow (or globally-down) experience. Routing users to the nearest region is only half the story; the data has to be there too. That half — replicating and serving data across regions — is a whole chapter of its own, and it's where this course goes next after we finish the front door.

Four beliefs that sound right and quietly mis-design global systems:

• "GeoDNS / anycast sends you to the geographically nearest region." Neither one measures geography. GeoDNS sends you to wherever the resolver looks like it is (ECS helps, doesn't guarantee); anycast sends you to the BGP-nearest by AS-path, which is frequently not the lowest-latency region. "Near" is an approximation in both.
• "A low TTL gives me instant DNS failover." No. Resolvers and clients routinely under-honor low TTLs to save work, so your real failover is "fast for the polite clients, minutes for the rest." The cache is a floor you don't control. If you need seconds, that's anycast's job, not DNS's.
• "Anycast is just a faster GeoDNS." Different layer, different failure mode. Anycast can flip a live TCP connection to a new PoP on reconvergence; GeoDNS never moves an established connection. That's why anycast fronts stateless/short traffic and you don't run your stateful app tier purely on it.
• "Global load balancing removes the single-region SPOF for free." Only if your data is multi-region. Nearest-region routing to a stack that still calls one faraway primary database just relocates the bottleneck and dresses it up. Global routing without global data is a prettier outage.

Fifteen minutes and a terminal, and the two mechanisms stop being abstract.

1. Watch anycast with your own eyes. dig +short a famous anycast IP — Cloudflare's 1.1.1.1 or Google's 8.8.8.8 — and note the answer. Now run the same query from a server on another continent (a cheap VM, or a free web "looking glass" / global-ping tool). Same IP, but a traceroute/mtr to it from each location lands in a different datacenter just a few hops away. One address, many places — the network chose for you.
2. Watch GeoDNS change its mind by location. Pick a big site on a GeoDNS/CDN (many are) and dig its name from two continents (again, use a looking glass or public resolvers in different regions) — you'll often get different IPs. Then simulate the resolver-location fix directly: dig +subnet=1.2.3.0/24 name @8.8.8.8 and change the subnet to a far-away one — watch the answer follow the client subnet you claim, which is EDNS Client Subnet doing its job.
3. Feel the TTL. dig a name, note its TTL, and query it again a few seconds later — watch the TTL count down in the resolver's cache. That countdown is exactly how long a stale answer would survive a failover. Try it against a record with a 300s TTL and one with a 30s TTL to feel the difference caches make.

The point isn't the commands — it's seeing, first-hand, that "which region" was decided either in a DNS answer that varies by where you ask from, or in a route that varies by where you are on the network.

Physics forces you to put datacenters on many continents, and Global Server Load Balancing is how each user reaches the nearest healthy one. The whole lesson comes down to when you decide which region:

• GeoDNS decides at the DNS answer — hand back a region-specific IP per user. You get rich control (geolocation for compliance, latency for speed, weighted, failover), but you pay for it: the answer is only as accurate as the resolver's location, and failover is only as fast as the slowest cache (TTL-bound, minutes in practice).
• Anycast decides in the network — one IP announced everywhere, BGP delivers each user to the nearest PoP. You get seconds-fast failover (withdraw the route, no caches to wait out) and DDoS absorption for free, but you give up fine control, route by BGP's idea of "near," and risk flipping a live TCP connection — so it fronts stateless, short traffic.
• Real systems layer them: anycast's fast, blunt edge over GeoDNS's smart, precise origin — the same fast-then-smart pattern as L4-in-front-of-L7, scaled to the globe.

And the thread through the whole load-balancing chapter holds: you route only to a healthy roster — it just grew from servers to regions.

We've now built a front door that spreads load, routes by content, survives dead servers, and reaches the whole planet. There's one job left before we leave the front door: it has to protect the servers behind it not just from failure, but from abuse — a flood of requests, malicious or accidental, that would drown a perfectly healthy fleet. Teaching the door to say "that's enough, slow down" is rate limiting — token buckets, leaky buckets, and sliding windows — and it's the next lesson.