Multi-Region Architecture and Global Scale
Understand geographic latency, regional failover, data placement, and the additional complexity of global systems.
Geographic Latency, Locality, and Edge Computing
Network distance imposes a lower bound on latency. Serving a user from a nearby region reduces round-trip time, but data may still need to travel to a distant primary database. Put latency-sensitive stateless compute near users when it helps, and decide deliberately where authoritative data lives.
Edge computing runs selected logic close to users, such as request routing, lightweight personalization, token checks, or content transformation. Edge runtimes may have limited execution time, storage, and networking capabilities. Do not move stateful business logic to the edge without understanding consistency and deployment constraints.
Locality can conflict with centralized correctness. A globally shared inventory item may require coordination across regions, while a regional catalog page can often tolerate replication lag. Classify data by locality and correctness requirements before selecting an active-active design.
- Geographic locality reduces network latency but complicates data ownership.
- Edge runtimes have constraints different from general servers.
- Not every dataset needs global strong consistency.
What is a central challenge of active-active writes to the same entity in multiple regions?
Active-Passive vs. Active-Active Regions
In active-passive architecture, one region serves primary traffic and another is prepared for failover. It is simpler to reason about writes but requires tested promotion, routing, and recovery. The passive region may be cold, warm, or nearly ready depending on cost and RTO.
Active-active serves traffic from multiple regions simultaneously. It can reduce latency and improve regional availability, but writes to the same data create conflict, coordination, or ownership questions. Common strategies include assigning each entity a home region, partitioning writes by geography, or using a database with a defined multi-region consistency model.
Do not confuse duplicated compute with a complete active-active system. Sessions, queues, rate limits, scheduled jobs, secrets, search indexes, and external integrations also need regional behavior. Test split-brain and partial-region failures, not only total region shutdown.
- Active-passive is simpler but still requires tested failover.
- Active-active needs explicit write ownership and conflict handling.
- Every stateful dependency must be included in the regional design.
Data Residency, Global Routing, and Failover Testing
Data residency requirements can constrain where personal or regulated data is stored and processed. A global architecture may need regional databases, regional encryption keys, restricted replication, and carefully controlled telemetry. Confirm legal requirements with qualified stakeholders rather than assuming all data can move freely.
Global routing can use DNS, anycast, or application-layer routing. DNS failover is not instantaneous because of resolver caching and client behavior. Health checks must avoid directing all traffic to a region that is reachable but unable to serve correct requests.
A regional failover plan should define detection, traffic shift, write fencing, data consistency checks, and failback. Failback is often harder than failover because the recovered region may contain stale or divergent data. Run regular game days and measure both recovery objectives and correctness after recovery.
- Residency constraints affect replication, backups, logs, and keys.
- Global routing has caching and health-detection delays.
- Failback and data reconciliation deserve explicit design and testing.