A stakeholder asks for multi-region. What three questions do you ask before agreeing?

What is being tested

Whether you can establish which of three very different drivers is actually in play, because each implies a different architecture.

The three questions

1. Is this a data residency requirement?

If a legal obligation says data must remain in a jurisdiction, this is a hard constraint and the conversation is over — you are building per-region data isolation with a thin global control plane holding no regulated data. Tenants are pinned to a region and routing resolves tenancy before touching data.

This is the strongest driver and it produces the clearest architecture.

2. Is this a latency problem?

If users far from the region experience slow responses, multi-region infrastructure is frequently the wrong answer. A CDN and edge compute address most latency concerns for read-heavy workloads at a fraction of the cost and complexity.

Ask what is actually slow: static assets and cacheable content are an edge problem; a write path genuinely requiring low latency for distant users is a region problem. The distinction saves a great deal of money.

3. Is this an availability requirement, and has the business priced it?

Regional failures are rare; the cost of multi-region is continuous. Ask for the RTO and RPO, per service, and what the business loses per hour of a regional outage. Frequently the honest answer is that a multi-hour recovery would be acceptable, in which case active-passive or even backup-and-restore is correct.

What multi-region actually costs

• Data consistency. Cross-region replication is asynchronous, so either you accept lag or you pay a round trip on every write.
• Doubled infrastructure, plus inter-region transfer charges.
• Operational complexity — per-region deployments, configuration drift, testing.
• The control plane must also be multi-region. Identity, secrets, deployment pipelines and observability — or the failover cannot be executed at the moment you need it. This is the most commonly missed requirement and it is the one that makes plans inoperable.

The topology worth proposing

Active-active partitioned by user or tenant is the most overlooked option. Each user has a home region that owns their writes, so there are no write conflicts to resolve, and a regional failure moves users rather than requiring global consensus.

It gives most of the benefit of active-active without the hardest part — which is why it is the right answer far more often than either active-passive or shared-write active-active.

The default to defend

If none of the three drivers applies, one region with multiple availability zones is correct, and it is correct for a large majority of systems.