Multi-Region Architecture

Overview

Multi-region architecture distributes an application across two or more geographic regions to achieve higher availability, lower latency for global users, and disaster recovery capability. A well-designed multi-region system can survive the complete loss of an entire data center or cloud region with minimal user impact.

Why Multi-Region?

Architecture Patterns

Pattern 1: Active-Passive (Warm Standby)

graph TB
    subgraph "Region A (Primary - us-east-1)"
        UsersA[Users] --> LB1[Load Balancer]
        LB1 --> App1[App Servers]
        App1 --> DB1[Primary DB]
    end
    subgraph "Region B (Standby - eu-west-1)"
        LB2[Load Balancer - Idle] --> App2[App Servers - Warm]
        App2 --> DB2[Replica DB]
    end
    DB1 -->|Async Replication| DB2
    DNS[Global DNS] -->|100%| Region A

Pattern 2: Active-Active

graph TB
    DNS[Global Load Balancer / DNS]
    DNS -->|Geo-routing| RegionA["Region A (us-east-1)"]
    DNS -->|Geo-routing| RegionB["Region B (eu-west-1)"]
    DNS -->|Geo-routing| RegionC["Region C (ap-southeast-1)"]

    subgraph "Region A"
        App1[App Servers] --> DB1[Database]
        DB1 <-->|Replication| DB2[Database]
    end
    subgraph "Region B"
        App2[App Servers] --> DB2
        DB2 <-->|Replication| DB3[Database]
    end
    subgraph "Region C"
        App3[App Servers] --> DB3
        DB3 <-->|Replication| DB1
    end

Pattern 3: Active-Active with Single Master

A common pragmatic approach: traffic is active in all regions, but writes go to a designated master region.

graph LR
    subgraph "Region A (Write Master)"
        Write[Write Traffic] --> MasterDB[Master DB]
    end
    subgraph "Region B (Read Replica)"
        Read[Read Traffic] --> ReplicaDB[Replica DB]
    end
    subgraph "Region C (Read Replica)"
        Read2[Read Traffic] --> ReplicaDB2[Replica DB]
    end
    MasterDB -->|Replication| ReplicaDB
    MasterDB -->|Replication| ReplicaDB2

Key Components

Global Traffic Management

Routing Strategies

Data Replication

Conflict Resolution Strategies

Stateful Session Management

Challenge: a user logs in on Region A, then hits Region B.

Best practice: stateless JWT + short expiry. Avoid sticky sessions in multi-region.

Database Topologies

Single Master, Multi-Region Replicas

        Region A (Master)
        ┌─────────────┐
        │  Primary DB │
        └──────┬──────┘
               │
     ┌─────────┼─────────┐
     │         │         │
  ┌──▼───┐ ┌──▼───┐ ┌──▼───┐
  │Repl 1│ │Repl 2│ │Repl 3│
  │Reg B │ │Reg C │ │Reg D │
  └──────┘ └──────┘ └──────┘

Writes go to Region A. Reads go to nearest replica. Failover promotes a replica to master.

Multi-Master

  Region A        Region B        Region C
  ┌─────────┐    ┌─────────┐    ┌─────────┐
  │ DB (RW) │◄──►│ DB (RW) │◄──►│ DB (RW) │
  └─────────┘    └─────────┘    └─────────┘
       ▲              ▲              ▲
       └──────────────┴──────────────┘
              Bidirectional
              replication

Failure Scenarios

Cost Optimization

Interview Questions

1. How would you design a multi-region e-commerce platform? Use active-active with a single write master for orders (strong consistency). Product catalog can be multi-master with CRDTs for inventory counters. Use global load balancer for geo-routing. Cache product data at CDN edge. Use canary deployments per region.

2. How do you handle database failover? Automated failover: health checks detect master failure, orchestrator (or managed service) promotes the most up-to-date replica. Critical: verify the replica is caught up before promotion (check replication lag). DNS update routes writes to new master.

3. What’s the RPO and RTO for active-active vs active-passive? Active-active: RPO ≈ 0 (sync replication), RTO ≈ 0 (automatic failover). Active-passive: RPO = seconds to minutes (async replication), RTO = minutes (DNS propagation + warm-up).

4. How do you test multi-region failover? Run chaos engineering: simulate region failure (shut down entire region), verify traffic reroutes, check data consistency post-failover, measure RTO. Run regularly (monthly game days), automate with tools like Chaos Monkey, Litmus.

5. What’s the biggest challenge in multi-region architecture? Data consistency across regions. The CAP theorem means you must trade off consistency for availability during partitions. Choose the right consistency model per data type: strong for financial data, eventual for social features, and always have a conflict resolution strategy.

Key Takeaways

• Active-passive is simpler and cheaper; active-active provides better latency and instant failover
• Global traffic management (DNS, CDN, anycast LB) routes users to the nearest healthy region
• Data replication is the hardest part: choose sync vs async based on consistency requirements
• Stateless application design (JWT, no sticky sessions) simplifies multi-region
• Plan for failure: chaos engineering, regular failover drills, automated runbooks
• Cost scales with the number of fully-provisioned regions — use scaling strategies
• Start with active-passive, evolve to active-active as the system and team mature

Cross-References

• CAP Theorem — Consistency-availability trade-off
• Replication — Replication strategies
• Consensus — Leader election for failover
• Cloud VPN — Cross-region connectivity
• Canary Releases — Per-region canary deployments
• Disaster Recovery — DR planning
• Chaos Engineering — Testing multi-region resilience