Global Server Load Balancing (GSLB)

Global Server Load Balancing (GSLB) solves a problem that no amount of optimization can fix: the speed of light.

A user in Singapore connecting to servers in Virginia experiences 200-300ms of latency just from the physical distance. That's not network congestion or slow servers—that's physics. Light through fiber can only go so fast.

GSLB accepts this reality and adapts. Instead of making one location faster, you put your application in multiple locations and send users to whichever is closest.

The Core Mechanism: Lying to Users

GSLB works by giving different answers to the same question.

When someone asks "where is example.com?", the answer depends on who's asking. A user in Tokyo gets an IP address in Tokyo. A user in London gets an IP address in London. Same domain, different destinations.

This happens at the DNS layer. Instead of returning a single static IP address, GSLB-aware DNS servers return different IPs based on:

• Where the user is (inferred from their DNS resolver's location)
• Which data centers are healthy (continuous health checks)
• Which locations have capacity (current load)
• Actual network performance (measured latency)

The user's device has no idea this happened. It just asked for an IP address and got one. The sophistication is invisible.

Routing Strategies

Geographic routing sends users to the nearest data center. Simple and usually effective—physical proximity correlates with low latency most of the time.

Latency-based routing measures actual performance rather than assuming geography equals speed. Sometimes a geographically distant location is actually faster due to network topology. This method finds those cases.

Weighted routing distributes traffic in specific ratios. Send 70% to your primary site, 30% to secondary. Useful for gradual migrations or managing capacity.

Failover routing designates primary and backup locations. Everything goes to primary until it fails, then everything goes to backup. Simple but effective for disaster recovery.

Geofencing restricts users to specific regions regardless of performance. European users must reach European servers—not because it's faster, but because regulations require it.

The DNS Trade-off: TTL

DNS responses are cached. When GSLB returns an IP address, that answer gets stored by DNS resolvers and the user's device for a duration called TTL (Time To Live).

Short TTLs (60 seconds) mean faster failover—if a data center dies, users get new answers quickly. But short TTLs create more DNS queries, increasing load and cost.

Long TTLs reduce DNS load but slow your response to failures. If TTL is 24 hours and your data center catches fire, users keep trying to reach it for up to 24 hours.

Most GSLB deployments use TTLs between 60 seconds and 5 minutes, balancing responsiveness against DNS query volume.

Anycast: The Alternative

DNS-based GSLB isn't the only approach.

With anycast, multiple locations announce the same IP address to the Internet's routing system (BGP). The Internet itself routes users to the nearest announcement point. No DNS tricks required.

This is how major CDNs work. The same IP address literally exists in dozens of locations. Users automatically connect to the closest one because that's how Internet routing works.

Anycast advantages: Instant failover (routing updates automatically when a location dies), works for any protocol, no DNS caching delays.

Anycast limitations: Requires control over BGP routing (not something most organizations have), less flexibility for custom logic, harder to implement weighted distribution.

Health Monitoring

GSLB only works if it knows which locations are healthy.

Health checks continuously probe each data center. Simple checks verify servers respond. Sophisticated checks verify the application actually works—correct responses, reasonable latency, acceptable error rates.

When a location fails health checks, GSLB removes it from DNS responses. Users asking "where is example.com?" no longer get that location's IP. Traffic automatically shifts to healthy locations.

The health check interval determines how quickly failures are detected. Check every 10 seconds and you catch failures fast. But aggressive health checking creates load on your servers and can cause flapping if transient issues trigger removal.

The Data Problem

Putting your application in multiple locations is easy. Keeping data consistent across those locations is hard.

Active-active deployments serve traffic from all locations simultaneously. Every location needs current data, which means synchronizing writes across regions. This is complex—what happens when two users update the same record in different regions at the same moment?

Active-passive simplifies this. One location handles all writes; others replicate from it. If the primary fails, a passive location becomes primary. Simpler, but you're paying for infrastructure that sits idle during normal operation.

Geo-partitioning avoids the synchronization problem entirely. European users' data lives in Europe. Asian users' data lives in Asia. No synchronization needed because data doesn't cross regions. This works well for compliance (data residency laws) but complicates scenarios where users travel or need to access data from other regions.

When GSLB Makes Sense

GSLB adds cost and complexity. You're running infrastructure in multiple regions, synchronizing data, managing DNS, and monitoring health across locations.

This makes sense when:

• Users are globally distributed and latency matters for their experience
• Availability requirements are high and single-region failure is unacceptable
• Regulations require data locality and you need to guarantee users reach specific regions

For applications with users in a single region or where latency isn't critical, GSLB is overkill. A single well-placed data center with good redundancy might be enough.

The Invisible Infrastructure

GSLB is one of those technologies users never see but always experience. When a website loads fast from anywhere in the world, GSLB is often why. When a major outage doesn't take down a service, GSLB is routing around the failure.

The mechanism is almost subversive—DNS is lying about where servers are, giving different answers to different people. But it's lying in service of a better experience. Users don't need to know the truth about IP addresses. They need fast responses and reliable service.

GSLB delivers both by accepting what physics won't let us change and engineering around it.