Global Load Balancer

In the previous page, we saw the DNS-based load balancer, which splits traffic when a user looks up our domain name. It worked for a few servers, but it was slow to react and blind to load. Now ShortLink has users in many countries. In this page, we solve that with the global load balancer.

Definition

A global load balancer sends each user to the best data center (a building full of servers) among several data centers in different regions.

Here is what breaks first. ShortLink runs in one data center in the US. A user in India opens sl.io/abc123. The request travels across the world and back.

1User in India → US data center
2Distance: about 13,000 km
3Round trip: about 250 ms before the server does any work ✗

The fix is to run ShortLink in several regions and send each user to a close one.

Analogy: a courier company with warehouses in many cities. An order from Mumbai ships from the Mumbai warehouse, not from New York. If the Mumbai warehouse is closed, the order goes to the next closest one.

1                              ┌→ Data Center: US
2User → Global Load Balancer → ├→ Data Center: Europe
3                              └→ Data Center: India

Each data center also has its own server-side load balancer and app servers. The global one only picks the data center. It does not pick the server.

Let's see how it decides.

How It Works

The global load balancer is usually built on DNS, with extra smarts. When a user looks up sl.io, it answers with the address of the best data center for that user.

11. User (India) asks DNS       "What is the address of sl.io?"
22. Global LB checks            where is the user? which data centers are healthy?
33. Global LB answers           India data center address
44. User → India data center    sends the request directly
55. Local load balancer         picks one app server inside

Another method is anycast. Many data centers share the same IP address. The internet's own routing sends each user to the closest one. This reacts faster than DNS because it does not depend on cached answers.

Next, let's look at the rules it can use to choose.

Routing Rules

Nearest is not always fastest. A close data center may be overloaded or have a poor network path. That is why many systems measure real latency instead of guessing from distance.

Here is the gain in numbers:

1Without global LB:  India user → US       ≈ 250 ms
2With global LB:     India user → India    ≈ 20 ms

Now, what if a whole data center fails?

Failover Across Regions

Here is what breaks. The India data center loses power. All its servers go down at once. A local load balancer cannot help, because the whole data center is gone.

The global load balancer health-checks each data center. When India fails, it stops sending users there.

1Normal:
2India users  → India data center
3Europe users → Europe data center
4 
5India data center fails:
6India users  → Europe data center   (next closest) ✓
7Europe users → Europe data center

Two things need care:

• Capacity. Europe must be able to handle its own users plus India's users. If not, the failure spreads. Say each data center runs at 60% of its limit. Two data centers share the load: 60% + 60% = 120% on one data center ✗. So teams keep spare room, for example running each data center at 40% or less.
• Data. The Europe data center needs ShortLink's links too. So data must be copied between regions (replication), which we cover in later pages.

1Capacity check with 3 data centers, each at 50% busy:
2India fails → its 50% is split between US and Europe
3Each gets +25% → 50% + 25% = 75% busy → still fine ✓

Failover is fast only if the user's lookup is fresh. With DNS-based routing, cached answers can still point to the dead data center until the TTL ends, as we saw in the last page.

Now let's compare the three types we have seen.

Global vs. Other Load Balancers

They work together in layers:

1User → Global LB → picks Data Center
2                    → Server-side LB → picks App Server

Advantages

• Lower latency. Users reach a nearby data center.
• Survives a whole data center failing. Not just one server.
• Handles regional spikes. Traffic from one region can spill to others.
• Follows local laws. Users' data can stay in their own region.
• Planned maintenance. Drain one region, upgrade it, and bring it back.

Limitations

1. Cost. Running several data centers is expensive. You pay for servers that sit partly idle to cover failover.

2. Data is hard. Every region needs the same links. Copying data between countries is slow and can briefly show different results in different regions.

3. More complexity. More parts, more monitoring, and harder debugging across regions.

4. Imperfect location. Finding a user's location from their address can be wrong, for example when they use a VPN.

5. Slow failover with DNS. Cached answers delay the switch.

6. Only needed at scale. A small product with users in one country does not need this.

When to choose it:

• Users in many countries who need fast responses.
• Systems that must stay up even if a whole data center fails.

When to avoid it:

• One country, small traffic. A single data center with a server-side load balancer is enough.

Summary

1Global load balancer → sends each user to the best data center in many regions
2→ Built on DNS (smart answers) or anycast (shared IP address)
3→ Rules: nearest, lowest latency, health-based, weighted, law-based
4→ Failover moves users to another region, but needs spare capacity and copied data
5→ Advantages: low latency, survives a data center failure, follows local laws
6→ Limits: high cost, hard data copying, more complexity
7→ Best for: users in many countries and very high availability

ShortLink can now serve users around the world from close data centers. But every redirect still reads from the database, and the same popular links are opened again and again. Keeping those hot links in memory is caching, our next topic.