AWS, Azure & GCP · Cloud across providers
How do you design a multi-region architecture?
Short answer
Replicate data and deploy independent stacks in multiple regions, then route users with latency or failover policies. The hard parts are data consistency, write conflicts, cost and operational complexity.
Multi-region starts with a reason: regulatory residency, lower latency for a global user base, or survival of a region-wide failure. Without a concrete driver, the extra cost and operational burden usually outweigh the benefit.
Topologies
- Active-passive: one region serves traffic, another stays ready for failover
- Active-active: both regions serve traffic, requiring conflict-aware data design
- Read-local, write-global: reads from nearby replicas, writes routed to a primary
- Global database services can simplify replication but still impose latency and consistency trade-offs
Data is the difficult part. Synchronous cross-region writes add latency and can fail when the link degrades. Asynchronous replication risks losing recent writes during failover. Multi-primary writes need conflict resolution, such as last-writer-wins, version vectors or application-level merging.
Operational requirements
- Independent deployments and configuration per region
- Global routing with health checks and a tested failover runbook
- Consistent identity, secrets and observability across regions
- Capacity reserved for failover, not just nominal traffic
- Regular region-loss exercises and clear data reconciliation steps
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When is multi-region worth the cost?
- 2How do you handle write conflicts in active-active?
- 3What happens to in-flight writes during a region failover?
- 4How would you test a region loss?
Say it in the interview
I only go multi-region for a concrete driver like residency, latency or region-level resilience. I replicate data and deploy independent stacks, then route with latency or failover policies. The hard part is data: synchronous writes add latency, asynchronous replication risks losing recent writes, and active-active needs conflict resolution. I define the failover runbook and test region loss before trusting it.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live AWS, Azure & GCP mock interview and get scored feedback on depth, clarity and confidence.