The business asks for multi-region active-active. Walk through the decision and what it actually requires.

Establish what problem it solves

Multi-region addresses region-wide failure and global latency. It does not address bad deployments, data corruption, configuration errors or dependency failures — which cause the large majority of outages, and which multi-region can make worse by propagating them faster and to more places.

If the last five incidents were deployments and configuration, multi-region is not the highest-value investment. Say so before designing it.

The options, in ascending cost

Backup and restore to another region — RTO in hours, RPO in hours. Cheap. Adequate for many systems.

Pilot light — data replicated continuously, minimal compute running, scaled up on failover. RTO in tens of minutes.

Warm standby — a scaled-down full environment. RTO in minutes, and crucially it is exercised, because it is running.

Active-active — both regions serving. RTO near zero, and by far the most expensive and complex.

What active-active actually requires

Data is the hard part, and it is a consistency decision, not a deployment topology.

Synchronous cross-region replication means every write pays 50–100 ms and the remote region becomes a write-path dependency. Asynchronous means accepting conflicts, and conflicts need a resolution strategy — last-write-wins (silent data loss), CRDTs (only for suitable data types), or application-level merge.

The usual escape is partitioning: each region owns a subset of the data (by customer, by geography), so writes are local and there are no conflicts. This is the design that works, and it constrains the product — a customer is served from their home region, and cross-partition operations are hard.

Also required: no single-region dependencies anywhere in the path (a shared identity provider, configuration store or feature flag service in one region defeats the whole design), global traffic management with health-based routing, and independent deployment pipelines so a bad release does not reach both regions simultaneously.

The organisational requirements

Both regions must serve real traffic continuously. A standby that has never taken load will not work when it must — the difference between active-active and an expensive illusion is whether it is exercised.

Regular failover exercises, including failback, which is harder and almost never rehearsed.

Operational maturity: everything must be automated, because manual processes do not survive a region failure at 03:00.

The recommendation

For most organisations: multi-zone first (which handles the realistic failure modes at a fraction of the cost), warm standby in a second region, and active-active only where the business case is explicit and the data model genuinely partitions.

Quantify it honestly: roughly 2× infrastructure, significant engineering investment, ongoing operational complexity, and a permanent constraint on the data model. Then compare against the measured cost of the downtime it prevents.