Global Load Balancing and Multi-Region Traffic Routing

Running an application in multiple regions can reduce latency, increase geographic resilience, and protect against regional infrastructure failures. The difficult part is deciding which region should receive each request and what should happen when that region becomes unavailable.

Global load balancing distributes traffic between geographically separated deployments rather than individual application instances. DNS routing, anycast, latency-aware policies, geographic routing, health checks, and failover rules work together to direct clients toward an appropriate healthy region.

Table of Contents

• Why Global Load Balancing Exists
• Global Routing Architecture
  • DNS-Based Routing
  • Anycast Routing
• Multi-Region Routing Strategies
  • Active-Passive Regions
  • Active-Active Regions
  • Latency and Geographic Routing
• Regional Failover and Failure Detection
• Data, Sessions, and Cross-Region State
• Production Design Example
• Common Mistakes
• Production Checklist
• Conclusion
• Key Takeaway
• More Articles to Read

Why Global Load Balancing Exists

A highly available application inside one region can survive server and availability-zone failures while still depending on the region itself.

Users
  |
  v
Region A
  |
  +--> Load Balancer
         |
         +--> Zone A
         +--> Zone B
         +--> Zone C

If Region A experiences a sufficiently large networking, control-plane, power, or service disruption, all availability zones may effectively become unreachable from the application's perspective.

A multi-region architecture adds another failure boundary:

                       Users
                         |
                         v
                  Global Routing
                    /         \
                   /           \
                  v             v
             Region A       Region B
                |              |
               LB             LB
              /  \           /  \
             v    v         v    v
           App  App       App  App

Global routing determines which region receives traffic. Regional load balancers then distribute that traffic across application instances or availability zones.

These layers solve different problems:

• Global load balancing: select a region or geographic deployment.
• Regional load balancing: distribute traffic inside the selected region.
• Service-level load balancing: distribute requests between individual service instances.

Multi-region deployment can also improve latency. A client in Europe may receive significantly better response times from a European deployment than from a deployment in North America.

However, adding another region does not automatically make a system resilient. Traffic routing, application capacity, data availability, dependencies, and operational processes must all support regional failover.

For high availability inside a region, see Designing Highly Available Load Balancing Architectures.

Global Routing Architecture

A global traffic layer needs a mechanism for directing clients toward regional endpoints. Two common approaches are DNS-based routing and anycast routing.

DNS-Based Routing

DNS-based routing returns different endpoint addresses according to routing policy and health information.

Suppose an application has two regional endpoints:

US Region
us.example.com
203.0.113.10

EU Region
eu.example.com
198.51.100.20

A global DNS service can answer requests for api.example.com differently:

Client in Texas
     |
     | DNS: api.example.com?
     v
Global DNS
     |
     +--> 203.0.113.10
          US Region


Client in Germany
     |
     | DNS: api.example.com?
     v
Global DNS
     |
     +--> 198.51.100.20
          EU Region

The routing decision can consider latency measurements, geography, configured weights, endpoint health, or primary/secondary failover rules.

Advantages:

• works with standard Internet infrastructure;
• supports geographic and latency-aware policies;
• can direct traffic between independent regional endpoints;
• does not require every packet to pass through one global proxy layer.

Disadvantages:

• DNS responses are cached;
• failover is not instantaneous;
• recursive resolvers can influence geographic decisions;
• clients may continue using an old endpoint after routing changes.

DNS TTL affects how quickly new answers can propagate, but setting a very low TTL does not guarantee immediate failover. Recursive resolvers, applications, operating systems, and clients may cache DNS information differently.

DNS failover should therefore be designed as eventually converging traffic movement, not an instantaneous switch.

Anycast Routing

With anycast, multiple geographically distributed locations advertise the same IP address. Internet routing directs clients toward an available network path to that address.

                    192.0.2.10
                    Global IP
                   /         \
                  /           \
                 v             v
          US Edge Location   EU Edge Location
                 |             |
                 v             v
             US Region      EU Region

Clients use one IP address while the network determines where traffic enters the provider infrastructure.

Anycast is common in global edge networks, CDNs, DNS systems, DDoS-protection networks, and globally distributed traffic services.

Advantages:

• one stable global address;
• traffic can enter infrastructure near the client;
• routing changes do not depend entirely on DNS cache expiration;
• works well with globally distributed edge networks.

Disadvantages:

• Internet routing optimizes network paths, not application health by itself;
• route changes can affect long-lived connections;
• implementation is significantly more complex without a managed provider;
• application-level regional selection may still be required behind the edge.

Multi-Region Routing Strategies

The global traffic layer still needs a policy for deciding how regions participate in production. The most important architectural distinction is whether regions operate active-passive or active-active.

Active-Passive Regions

In an active-passive architecture, one region normally receives production traffic while another region exists primarily for disaster recovery.

                  Global Routing
                   /          \
                  /            \
             100% traffic    standby
                 |              |
                 v              v
             Region A        Region B
              ACTIVE         PASSIVE

If Region A becomes unhealthy, traffic moves to Region B.

Advantages:

• simpler application traffic model;
• fewer cross-region write conflicts;
• easier reasoning about primary data ownership;
• useful when the second region primarily exists for disaster recovery.

Disadvantages:

• standby infrastructure may be underutilized;
• failover can require application and data promotion;
• standby capacity may not be continuously validated by production load;
• recovery time can be longer than active-active routing.

A passive region does not necessarily need zero traffic. Synthetic requests, internal traffic, or a small production percentage can continuously verify that the region remains operational.

Active-Active Regions

In an active-active architecture, multiple regions serve production traffic simultaneously.

                         Users
                           |
                           v
                    Global Routing
                     /          \
                    /            \
                   v              v
              Region A        Region B
                60%             40%
                 |               |
                 v               v
            Production      Production
             Traffic         Traffic

If Region A fails, Region B can receive redirected traffic.

Advantages:

• regional infrastructure is continuously exercised;
• users can be routed toward nearby regions;
• failover starts from already-active infrastructure;
• capacity contributes to normal production instead of remaining idle.

Disadvantages:

• data architecture becomes substantially more difficult;
• cross-region consistency must be defined explicitly;
• concurrent writes can create conflicts;
• regional dependencies must behave correctly under partitions;
• each surviving region needs enough failover capacity.

Active-active compute is relatively straightforward compared with active-active data. Application servers can be duplicated easily; strongly consistent writable state across distant regions has unavoidable latency and availability trade-offs.

Latency and Geographic Routing

Active-active systems need a method for selecting the preferred region.

Latency-based routing attempts to send clients to the region expected to provide the lowest network latency.

Client A
  |
  +--> US Region:  28 ms
  +--> EU Region: 112 ms
  |
  +--> choose US


Client B
  |
  +--> US Region: 135 ms
  +--> EU Region:  24 ms
  |
  +--> choose EU

Geographic routing uses client location or network geography to apply explicit regional policies. For example, European traffic might be routed to an EU deployment while North American traffic uses a US deployment.

Geographic routing can be important for data residency, regulatory requirements, contractual constraints, or intentionally partitioned datasets. The nearest region is not always the legally or operationally correct region.

Weighted routing provides another option:

US Region: 70%
EU Region: 20%
New Region: 10%

This can support migrations, capacity management, regional canaries, or controlled traffic transitions.

Weighted routing is also useful during deployments. More about progressive traffic movement can be found in Traffic Routing Strategies for Zero-Downtime Deployments.

Regional Failover and Failure Detection

Regional failover requires a reliable answer to a difficult question: when should an entire region stop receiving traffic?

One unhealthy application instance is not a regional failure. Neither is a single unavailable zone or a temporary increase in latency.

Global health should normally evaluate the regional service endpoint rather than individual backend processes:

Global Health Checker
        |
        +----> Region A public endpoint
        |         |
        |         +--> regional load balancer
        |         +--> application fleet
        |
        +----> Region B public endpoint
                  |
                  +--> regional load balancer
                  +--> application fleet

A health policy might conceptually use:

regions:
  us:
    endpoint: https://us.example.com/health
    priority: 1

  eu:
    endpoint: https://eu.example.com/health
    priority: 2

failure_detection:
  interval_seconds: 10
  timeout_seconds: 3

  # Avoid regional failover because of one transient failure.
  unhealthy_threshold: 3

recovery:
  # Require repeated success before restoring traffic.
  healthy_threshold: 5

Production implementations should preferably perform checks from multiple independent locations. A health checker in one network location can mistake a local connectivity problem for a regional outage.

Failover also changes load:

Before failure:

Region A --> 6,000 req/s
Region B --> 4,000 req/s


Region A fails:

Region B --> 10,000 req/s

If Region B can process only 7,000 requests per second, routing successfully fails over while the application still fails from overload.

Failover capacity must be planned before failure. Autoscaling can help restore headroom but may not react quickly enough to absorb an immediate regional traffic shift.

Recovery requires similar care. If a previously failed region passes one health check and immediately receives 50% of global traffic, cold caches, connection pools, databases, and application instances can be overwhelmed.

Traffic should often return gradually:

Recovered Region A

0% --> 5% --> 20% --> 50% --> normal allocation

This provides time to validate the region under real traffic and rebuild caches and connection pools safely.

Data, Sessions, and Cross-Region State

Traffic routing is only one part of multi-region architecture. The selected region must also have access to the data required to process the request.

Consider an application with users routed to either region:

               Global Router
                /         \
               v           v
           Region A     Region B
               |           |
               v           v
          Database A   Database B

If databases replicate asynchronously, a write in Region A may not immediately exist in Region B.

1. User writes in Region A
2. Response succeeds
3. Region A fails immediately
4. User moves to Region B
5. Latest write has not replicated yet

This is a traffic failover success but potentially a data consistency failure.

Multi-region systems must explicitly define:

• which regions can accept writes;
• how data replicates;
• acceptable replication lag;
• what happens during network partitions;
• how concurrent writes are resolved;
• whether users require read-after-write consistency;
• what data can legally move between regions.

One common model assigns a home region to each tenant or dataset:

Tenant A --> Region US
Tenant B --> Region EU
Tenant C --> Region US
Tenant D --> Region EU

Global routing can then consider data ownership instead of simply selecting the lowest-latency region.

Another model allows reads from several regions but sends writes to one primary region. This simplifies write consistency at the cost of additional write latency for distant clients.

Fully multi-region writes provide more flexibility but require explicit conflict and consistency semantics. There is no routing policy that can eliminate these data-system trade-offs.

Session architecture matters as well. Sessions stored only in one region may disappear from the client's perspective after regional failover. Shared or replicated session infrastructure can solve this, but it adds cross-region state complexity.

Stateless application instances reduce dependence on individual compute nodes and make regional traffic movement easier. For a deeper explanation, see Sticky Sessions and Stateless Applications.

Production Design Example

Consider a SaaS API serving customers in North America and Europe. The service needs low client latency and must continue operating if one application region becomes unavailable.

The platform runs active-active application infrastructure in two regions:

                          Clients
                             |
                             v
                  +---------------------+
                  | Global Traffic      |
                  | Routing             |
                  +---------------------+
                     /               \
                    /                 \
             latency / health     latency / health
                  /                     \
                 v                       v
        +----------------+      +----------------+
        | US Region      |      | EU Region      |
        +----------------+      +----------------+
                |                       |
                v                       v
        Regional Load           Regional Load
          Balancer                Balancer
           /    \                  /    \
          v      v                v      v
        App    App              App    App
         |      |                |      |
         +--+---+                +--+---+
            |                       |
            v                       v
        Regional Data <------> Regional Data
             Store             Store
                cross-region replication

Under normal operation, clients are routed toward the preferred region based on latency and application policy.

The global health system checks both regional endpoints from several locations. A single failed probe does not trigger failover. Multiple consecutive failures across independent health-check locations are required before the region is removed.

Inside each region, a separate load balancer handles instance and availability-zone failures. Global routing therefore does not need to react when one application instance fails:

App instance fails
      |
      v
Regional load balancer removes target
      |
      v
Region remains healthy
      |
      v
No global failover


Entire regional endpoint fails
      |
      v
Global health checks fail
      |
      v
Region removed from global routing
      |
      v
Traffic moves to surviving region

This separation prevents small failures from triggering unnecessarily large traffic movements.

Capacity planning assumes the surviving region may temporarily receive almost all eligible traffic. If each region normally runs near 80% utilization, the architecture cannot safely fail over without aggressive load shedding or rapidly available additional capacity.

The system therefore maintains regional headroom and defines degraded-mode behavior for expensive noncritical operations. Reliability techniques such as load shedding and graceful degradation can keep core requests available when failover reduces capacity. More about these patterns can be found in Designing Graceful Degradation Strategies.

Data behavior is defined independently from traffic behavior. If some records cannot safely accept writes in the secondary region because replication is asynchronous, those operations return a controlled temporary failure or enter a degraded mode rather than pretending that traffic failover guarantees data correctness.

This distinction is critical: multi-region routing decides where requests go; the data architecture determines what those requests can safely do after they arrive.

Common Mistakes

Production Checklist

• Define regional failure requirements: decide which regional outages the system is expected to survive.
• Choose active-passive or active-active intentionally: match the model to recovery objectives, cost, and data architecture.
• Separate global and regional health: avoid escalating instance failures into regional failovers.
• Use multiple health-check locations: reduce false failover caused by one monitoring network path.
• Plan DNS convergence: account for resolver and client caching when DNS controls failover.
• Capacity-plan the surviving region: verify it can handle redirected production traffic immediately.
• Maintain failover headroom: do not assume autoscaling will provide capacity instantly.
• Define data ownership: know where each dataset can be read and written.
• Measure replication lag: understand potential data loss or staleness during failover.
• Design session behavior: ensure regional movement does not unexpectedly invalidate active users.
• Control recovery traffic: gradually restore a recovered region instead of immediately returning full load.
• Monitor per-region metrics: track latency, errors, saturation, healthy capacity, and traffic distribution separately.
• Test regional evacuation: deliberately remove one region and observe routing, capacity, and dependencies.
• Verify dependency locality: ensure the secondary region does not depend critically on services available only in the failed region.
• Document degraded behavior: define which operations remain available when full cross-region consistency or capacity is unavailable.

Conclusion

Global load balancing extends traffic management beyond individual servers and availability zones by routing requests between geographically separated regions. DNS-based routing, anycast, health checks, latency policies, and geographic rules provide the mechanisms, while active-passive and active-active architectures define how regions participate in production.

The difficult part is not creating a second regional deployment. The difficult part is making traffic, capacity, data, sessions, dependencies, and recovery behavior continue working when one region disappears.

Key Takeaway

Multi-region availability requires traffic routing and data architecture to be designed together. Global load balancing can redirect requests away from a failed region, but successful failover also requires sufficient capacity, usable data, healthy dependencies, predictable session behavior, and controlled recovery. A second region becomes resilience only when it can safely serve the traffic and operations that move to it.

More Articles to Read

• Load Balancing Explained: Distributing Traffic at Scale
• Round Robin vs Least Connections vs Consistent Hashing
• Designing Highly Available Load Balancing Architectures
• Sticky Sessions and Stateless Applications
• Traffic Routing Strategies for Zero-Downtime Deployments
• Load Balancing Best Practices for Production Systems