Global Server Load Balancing
In one line: before any load balancer picks a server, something has to pick a data center. That decision determines a user's baseline latency and is your first line of defense when an entire region goes dark.
What GSLB does
GSLB intelligently forwards global traffic to the optimal data center, making decisions based on:
- User location — send people to a region near them.
- Server capacity — do not send traffic to a region that cannot absorb it.
- Data center health — if a region suffers a power or network failure, reroute to an active location.
GSLB also enables automatic zonal failover, and can be deployed on-premises or consumed as load balancing as a service (LBaaS).
The control-plane feedback loop
This is the part that makes GSLB more than a static map, and it is worth being precise about.
In a typical setup, GSLB forwards requests to specific data centers. The local load-balancing layer in each data center maintains a control-plane connection back to the GSLB, reporting the health of both the load balancers and the server farm behind them. GSLB uses that monitoring data to drive traffic decisions according to regional configurations.
Data plane versus control plane, again
This is the same split from the Foundations module. The data plane carries user traffic to a region. The control plane carries health and capacity information back the other way. They run at completely different rates — millions of requests per second downward, health reports every few seconds upward — and they fail independently.
Naming this split explicitly is a strong signal. It also sets up the right follow-up question: what happens if the control plane is partitioned but the data plane is fine? The safe answer is static stability — keep routing on the last known good configuration rather than assuming a silent region is dead.
DNS as the primary GSLB mechanism
The Domain Name System is a primary mechanism for performing GSLB. As DNS established, a DNS query can return multiple IP addresses, and the system distributes load by reordering that list in its response — often visible by running nslookup repeatedly. Different users receive different primary servers, which effectively distributes requests across data centers. DNS commonly uses round robin to rotate the IP order.
Where DNS round robin falls short
Two limitations matter enough to design around:
| Limitation | Cause | Effect |
|---|---|---|
| Uneven load distribution | ISPs with large user bases may cache a single IP address | All of that ISP's users go to one server, creating imbalance |
| Lack of failure detection | Round robin does not account for server crashes | It keeps handing out a failed server's IP until the cached entry's TTL expires, hurting availability |
Despite these, round robin is widely used. Providers mitigate it with short TTL values on cached entries to keep distribution effective and shorten the failure window.
Two ways to do global traffic management
So — can DNS be considered a GSLB? Yes, but typically via custom DNS infrastructure. There are two common approaches to global traffic management (GTM):
| Approach | How it works | Strength |
|---|---|---|
| GTM through ADCs | Application delivery controllers forward requests based on real-time data such as server health and data center capacity | Reacts to live conditions rather than a cached answer |
| GTM through DNS | Authoritative DNS servers respond based on the IP of the DNS resolver (usually near the user), directing traffic to the geographically or topologically nearest data center — or by policies like latency or availability | Works with every client on earth, no special software required |
The DNS approach is typically achieved through managed DNS providers — AWS Route 53, Cloudflare — or custom infrastructure incorporating geolocation and health data.
Key takeaway
GSLB chooses the region; it is coarse, health-aware through a control-plane feedback loop, and largely implemented over DNS. Its weaknesses — cached answers, slow failure detection, resolver-based geography — are exactly what the local layer exists to compensate for.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We use DNS to send users to different data centers." |
| L5 | Knows the limits: "DNS round robin distributes across regions, but it can't detect a crash quickly and one big ISP resolver skews the split." |
| Staff+ | Describes the loop and the fallback: "local LBs report health up a control plane so GSLB routes on live capacity, not a static map. And if the control plane partitions I'd stay statically stable on the last good config rather than treat silence as failure." |
Next: the layer that fixes what DNS cannot.