Global server load balancing (GSLB)

What is global server load balancing?

Global server load balancing, usually shortened to GSLB, is the practice of steering users to one of several service locations. The locations might be separate data centers, cloud regions, origin pools, CDN origins, or active and standby environments. The choice can be based on health, latency, geography, capacity, business policy, or a combination of those signals.

The goal is not simply to spread traffic. A useful GSLB design keeps users close to healthy capacity, reduces the chance that one failed region takes the whole service down, and gives operators a controlled way to drain, fail over, or migrate traffic. It sits above ordinary server load balancing because the decision crosses sites or providers rather than just choosing a node inside one cluster.

Where the decision happens

GSLB can be implemented at different layers. DNS-based GSLB returns different addresses or hostnames depending on resolver location, health state, or weight. CDN and reverse proxy based GSLB can choose an origin after the user has already reached the edge. Application gateways can make route decisions with more request context, such as path, host, cookie, or tenant.

Each layer has tradeoffs. DNS is widely compatible and can move large amounts of traffic without every request passing through one control point, but resolver caching means changes are not instant. Edge or proxy routing can react faster and can use more request details, but it depends on that edge service remaining available and correctly configured. Application-level routing can be precise, but it may be too late to avoid network distance or regional outage effects.

Many real designs use more than one layer. DNS may send a visitor to a nearby edge network, the edge may choose an origin pool, and the origin pool may still use local load balancing. That is normal, but it makes documentation and logging important. During an incident, teams need to know which layer made the decision they are observing.

Common traffic policies

The simplest policy is active-passive failover: use the primary region while it is healthy, then send traffic to a backup. This is easy to explain, but the backup must be sized and tested or the failover only moves the outage. Active-active designs send normal traffic to multiple regions. They can improve latency and capacity, but they introduce data consistency, deployment coordination, and regional policy challenges.

Weighted routing is useful for migrations, canary releases, capacity balancing, and gradual failback after an incident. Geographic routing can keep users near a region or inside a compliance boundary, but geography is an imperfect proxy for network performance. Latency-based routing can improve user experience, but only if measurements are current, representative, and stable enough not to cause constant movement.

Health-based routing is essential, but health checks need to test the right thing. A TCP connection or empty HTTP 200 might prove that a server process is alive while checkout, login, search, or database access is broken. Good health checks represent the route being protected without creating excessive load or requiring fragile dependencies.

Designing for cache and origin behavior

GSLB changes how caches warm and how origins absorb misses. If users can be sent to several origins, each origin may see a different cache miss pattern. A multi-region site may have excellent global availability but poor cache efficiency if every region rebuilds the same expensive pages after a purge.

Route-aware cache policy helps. Static assets, product images, documentation, and public pages can often tolerate longer freshness or controlled stale serving. Authenticated pages, carts, admin paths, and state-changing APIs need stricter handling. If the GSLB layer sends a request to another region during an outage, operators should know whether cached content remains valid, whether writes are safe, and whether the user may see older data.

Origin shielding or request collapsing can reduce duplicated fetches when several edge locations miss at once. In a GSLB environment, place those controls deliberately. A shield that is far from all origins may add latency. A shield tied to one region may become a bottleneck during failover. The right choice depends on the origin topology and the cost of cache misses.

Failure modes to plan for

The most common misconception is that GSLB automatically makes an application highly available. It only routes traffic. The application still needs replicated data, consistent configuration, valid certificates, capacity in the alternate location, and security controls that behave the same way after traffic moves.

DNS caching is another common surprise. Low TTLs help, but resolvers and clients may still cache answers longer than expected. Existing connections may continue to use an old path. Mobile networks, corporate resolvers, and regional ISPs can all behave differently, so failover should be tested from more than one network.

Health checks can also flap. If the threshold is too sensitive, brief dependency issues may move traffic unnecessarily. If it is too slow, users stay on a failing region. Recovery needs equal care: sending all traffic back to a newly recovered region can overload cold caches and recovering databases.

Inconsistent policy across regions is a frequent security problem. The backup hostname may have weaker WAF rules, missing rate limits, older TLS settings, or direct origin access left open for testing. Attackers look for those differences because failover paths often receive less scrutiny than the primary site.

How to evaluate a GSLB setup

Start by drawing the request path for each important hostname. Include DNS providers, edge services, origin pools, regional load balancers, health checks, certificates, cache rules, and application dependencies. Then classify routes by risk: public static, public dynamic, authenticated, write-heavy, administrative, and machine-to-machine API traffic.

Test the intended policy with evidence. Query DNS from multiple resolver networks. Use synthetic checks from several regions. Compare edge logs, origin logs, cache status, response codes, and latency during normal traffic and controlled failover. Confirm that the observed origin matches the policy decision, not just that the page returned a 200.

Run planned failover exercises. Drain a region, fail it, restore it, and fail back. Watch error rate, origin request rate, cache hit ratio, byte hit ratio, database health, queue depth, login success, and user-facing latency. Pay attention to recovery, not only the moment of failure.

Operational and security signals

A reliable GSLB system needs visibility into health check state, DNS answers, edge location, selected origin, origin status, latency, cache outcome, TLS errors, and policy actions. Global averages are not enough. Break results down by region, ASN, hostname, route, and origin pool where possible.

Ownership should also be explicit. DNS weights, origin pools, health check definitions, certificates, cache rules, and security policy are production controls. They need review, audit history, rollback steps, and runbooks. GSLB works best when it is treated as part of the application delivery design, not as an emergency switch that only one infrastructure team understands.