Multi-Region Deployment

Overview

Multi-region deployment spreads a service across geographic regions. It protects against the loss of an entire region, which multi-zone designs cannot, and puts compute closer to users.

How it works

Traffic enters through global routing that checks health and proximity. Each region runs a full, self-sufficient stack. Data placement decides the model.

        global DNS / anycast LB
          /                \
   region A              region B
   app + cache           app + cache
   DB primary  <--async--> DB replica

Common data models: active-passive, with a replica promoted on failure; active-active with per-user home region; or multi-leader with conflict resolution such as last-write-wins or CRDTs. Capacity planning rule: with N regions, each should carry enough headroom to absorb its share of a failed one, roughly one over N minus 1 extra load.

Pitfalls

• Untested failover. Run game days that actually shift traffic.
• Assuming async replication is lossless; define an acceptable recovery point and communicate it.
• Hidden single-region dependencies such as a global control plane, identity provider or build system.
• Deploying to all regions simultaneously, which removes the fault isolation benefit. Stagger rollouts.
• Ignoring cross-region data transfer cost and latency of chatty calls.
• DNS caching that delays failover beyond the target.

Key takeaways

• Regions are independent failure domains; keep them independent.
• Decide the data and consistency model first.
• Provision failover headroom and verify it.
• Roll out region by region.
• Rehearse failover until it is routine.