Why Global Server Load Balancing (GSLB) Is Hard: Technical Challenges and Solutions

What Is GSLB?

GSLB stands for Global Server Load Balancing (also called Global Software Load Balancing or Global Site Load Balancing) and refers to distributing traffic across globally distributed sites.

According to Wikipedia: Load balancing distributes workloads across multiple computing resources to optimize resource usage, maximize throughput, minimize response time, and avoid overload.

Beyond resource optimization, large Internet companies use GSLB to achieve two additional goals:

Increase system availability – if one site or cluster becomes unavailable, traffic can be served by other sites.

Reduce user latency – requests are directed to the nearest site based on user geography.

Why It’s Hard

Hard means building a GSLB system that meets the three goals above is difficult.

It is not about merely implementing a GSLB system, but about achieving availability, latency reduction, and accurate load distribution.

The difficulty can be explained from three perspectives: underlying technology, operation & maintenance, and functional implementation. This article covers the first part – the underlying technology.

Underlying Technology

We focus on DNS‑based GSLB because DNS is the oldest and most widely used global load‑balancing mechanism, supporting all upper‑layer protocols.

Almost every GSLB implementation relies on DNS; many simple GSLB solutions are pure DNS‑based, while more complex ones add extra components but still use DNS as the first layer.

HTTP‑based redirection GSLB exists but has significant limitations and is not discussed further.

Below is a simple DNS‑based GSLB architecture diagram:

When a user accesses www.example.com , two key information flows occur:

Local balancers report metrics to a global balancer, which aggregates the data and updates the authoritative DNS.

The user’s ISP DNS recursively resolves www.example.com, receives an IP from the authoritative server, and the browser contacts the corresponding server cluster.

Problems with DNS‑Based Load Balancing

The ideal state shown in the diagram (NYC and LON users reaching the nearest cluster) is hard to maintain in practice.

1. Returning the Optimal IP

Typically the authoritative DNS returns the IP of the nearest cluster based on the source IP of the DNS query. If the client’s ISP uses a distant recursive resolver, the returned IP may be far from the client.

EDNS‑client‑subnet can help if supported, allowing the client’s subnet to be considered when selecting the IP.

Supported providers can be found at http://www.afasterinternet.com/participants.htm , though the list is incomplete and adoption is slow.

2. Accurate Traffic Steering

Simple DNS load balancing suffers from uneven traffic distribution due to DNS caching and limited edns‑client‑subnet support.

ISP DNS caches results, causing one DNS query to affect many subsequent service requests.

Many resolvers do not support edns‑client‑subnet, leading to cross‑region traffic and degraded user experience.

Since providers cannot control end‑user DNS settings, traffic adjustments must be performed on the server side.

3. Fast Failover

When a failure occurs, quickly diverting traffic is critical, but DNS‑based failover is unreliable because of client, ISP, and public DNS caching, as well as non‑compliant TTL handling.

Anycast offers a more reliable solution: each cluster announces the same VIP via BGP, and routers direct users to the nearest reachable VIP. If a cluster fails, its VIP is withdrawn and traffic automatically routes to the next best cluster.

Dyn’s anycast points illustrate this approach:

Another method is using BGP communities to set primary/backup routes for IP blocks.

Latency Control System

When a GSLB system includes intra‑cluster traffic scheduling, it forms a feedback loop, becoming a latency‑controlled system.

The data flow involves local services reporting load to local balancers, which report to the global balancer; the global balancer computes traffic distribution, updates DNS, and local balancers adjust traffic accordingly. This loop is not instantaneous; reporting intervals and computation delays introduce latency.

A Global System

Scaling this loop globally introduces challenges such as inter‑data‑center latency, cross‑network traffic from frequent reporting, and high computational demands.

Inability to Handle Short Spikes

GSLB cannot cope with brief traffic spikes; it assumes traffic does not change dramatically in short periods.

Consequently, sudden short‑duration overloads (e.g., a 5‑second DDoS burst) may go unnoticed, leading to potential cascading failures.

Summary

Improve DNS protocol and edns‑client‑subnet adoption.

Introduce server‑side feedback to mitigate DNS caching issues.

Use network‑layer techniques like anycast and backup routing for rapid failover.

Remaining inherent challenges include latency control, global coordination, and traffic assumptions.