Why go multi-region

Multi-region means running your system in two or more geographic regions. Each cloud region contains several availability zones, and each zone is a data center with its own power and network. Multi-region is for problems that span a whole region. You take it on for one of three reasons.

The big idea

There are three legitimate reasons:

• Latency. Users far from your servers wait for every round trip.
• Disaster tolerance. You survive losing a whole region. The cause might be a provider outage, a natural disaster, or your own bad deploy that happened to hit one region.
• Regulation. Data-residency laws and contracts can require certain data to stay in one jurisdiction.

The costs are real:

• Money. Each region needs enough capacity to absorb a failed region's traffic. Cross-region transfer is billed per GB, and replicating a busy database can cost as much as the database.
• Consistency. Strongly consistent writes across continents pay the speed of light on every write. Every design becomes a choice about which data gets which consistency.
• Complexity. Pipelines, configuration, secrets, monitoring and on-call all multiply. Failover is a distributed-systems problem with humans in the loop.

Walking through it: the latency floor

Light in fiber covers roughly 200 km per millisecond. New York to London is about 5,600 km, which is 28 ms one way. A round trip therefore has a physical floor of about 56 ms, and real networks land around 70 to 80 ms.

A user in Sydney calling a server in Virginia pays about 200 ms per round trip. A page that needs four sequential round trips spends about 800 ms on the network alone, however fast the code is:

round trips needed              4
Sydney to Virginia, per trip    ~200 ms
network time alone              4 x 200 ms = 800 ms

A CDN fixes this for static content. For dynamic reads and writes, you need compute and data closer to users, which is what multi-region gives you.

Residency is a broader rule than routing. If EU personal data must stay in the EU, every replica, backup, log and search index derived from it must stay there too. A regional primary database whose logs ship to a central logging cluster in another country breaks that rule.

Common mistakes

• Going multi-region for vague resilience. Without a target, such as surviving a region outage with a stated amount of downtime, you can't tell when the design is done.
• Forgetting the transfer bill. Cross-region replication is billed per GB, and busy systems move a lot of it.
• Skipping zone-level resilience. A single-zone service with a second region is fragile in both places.

Check yourself

1. Why is a round trip between New York and London at least about 56 ms?

   Light in fiber covers about 200 km per millisecond. The 5,600 km takes 28 ms one way, so 56 ms there and back.

2. What failure does a three-zone deployment survive that a single zone does not?

   The loss of one data center, for example in a fire, while the other zones keep serving.

Key takeaways

• Multi-region is for latency, regional disaster tolerance and residency.
• The speed of light sets a latency floor that no code change removes.
• Multi-zone deployment covers most failures far more cheaply.
• Residency covers every copy of the data, not only the primary.

Further learning

Next: active-passive, RPO and RTO, which covers the simplest multi-region design and its recovery numbers.