Multi-region architecture

Running in several regions protects against a regional outage and brings data closer to users. The hard part is data: synchronous replication adds cross-region latency to writes, asynchronous replication risks losing recent writes.

Where it shows up in real systems

  • Global load balancer

    A single anycast IP attracts users to the nearest point of presence, then traffic rides the provider backbone to the best region. Unlike DNS failover, switching regions does not wait for resolver caches to expire.

    In production: AWS Global Accelerator, Google Cloud global external LB, Azure Front Door, Cloudflare Load Balancing

  • Distributed SQL

    Each write is committed through a consensus protocol (Raft or Paxos), so it is never lost and every read is up to date, even across regions. The price is latency: a write must reach a majority of replicas, and across regions that means tens of milliseconds.

    In production: Google Cloud Spanner, CockroachDB, YugabyteDB, TiDB, Amazon Aurora DSQL

  • Inter-region link

    Carries replication and service traffic between regions. Synchronous replication over it adds the full round-trip time to every write; asynchronous replication risks losing the last seconds on failover.

    In production: AWS Transit Gateway, VPC peering, Azure Global VNet Peering

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox