The business asks for "multi-region" after a regional outage. Before agreeing, what do you need to establish, and what are you actually signing up for?

What the interviewer is testing

Whether you convert a vague requirement into numbers before designing, and whether you know that multi-region is primarily a data problem.

Establish first

Are we solving the right problem? Multi-region defends against a region-wide failure. If the outage was a bad deployment, an expired certificate or a database running out of connections — which most are — a second region defends against none of it and doubles the surface for the next one. Ask what actually happened.

RTO and RPO. Everything follows from these two numbers, and the cost is steeply non-linear:

Which data must be consistent across regions? This is the decision that determines whether the project is difficult or merely expensive.

What you are signing up for

Data. Synchronous cross-region replication adds inter-region latency to every write — 60–90 ms between continents, and it is physics, not a tuning problem. Asynchronous replication means an RPO greater than zero and, in active-active, the possibility of conflicting writes that need a resolution strategy. There is no third option.

Traffic management. Global load balancing, health checks that distinguish "region degraded" from "check is broken", and a tested failover path. DNS-based failover is slower than its TTL suggests because resolvers ignore TTLs.

Operational load. Every deployment, migration and configuration change now happens twice, and the window where the regions differ is a new class of bug.

Cost. Double the compute, plus cross-region data transfer, which is the line item that surprises people.

The recommendation to make

For most systems: multi-AZ within one region (which handles the physical failures cheaply), plus a warm standby in a second region with a tested failover, plus attention to the deployment and configuration failures that cause most real outages.

Active-active is right when the requirement is genuinely zero RPO and seconds of RTO, or when users are globally distributed and latency demands local serving. It should be a decision made with the data consistency implications on the table, not an aspiration.

What a strong answer adds

Asking whether the workload can be partitioned so each region owns a disjoint set of data — users homed to a region, with cross-region access being a rare slow path. That converts an active-active consistency problem into two single-region systems, and it is the design most large systems actually use.