advanced 2 min answer

You run active-active across two regions. The link between them fails. What should each region do, and what would you have designed differently?

partitionquorummulti-regionavailability
Show the full answer Hide the answer

The immediate answer

Neither region can safely keep accepting writes to shared state, because neither can know it is the surviving side. Each sees one of two nodes — there is no majority, so there is no way to distinguish "the other region is down" from "the other region is up and I am the one that is isolated".

If both accept writes, you get divergence with no correct merge for anything carrying a shared invariant: a balance, a stock count, a uniqueness constraint. That is unrecoverable, not inconvenient.

So the options during the partition are:

  1. A pre-designated primary — one region continues, the other goes read-only. Simple, and it means a failure of the primary region requires a human decision.
  2. Both read-only for the affected data, continuing to serve reads and queueing writes.
  3. Both continue — acceptable only for data with no shared invariant (append-only events, independent per-user data) or with a genuinely commutative merge.

What I would have designed differently

A third site for quorum. Two regions cannot form a majority between themselves. An arbiter — even a lightweight witness holding no data — in a third region restores the ability to make a decision automatically. This is the single most valuable change and it is cheap.

Partition the data by home region. Instead of shared global state, home each customer to a region that owns their writes. Cross-region access becomes a rare slow path. This converts an active-active consistency problem into two single-region systems, and it is what most large systems actually do.

Separate the data by invariant. Not all data needs the same treatment. Session state, analytics and audit events can be AP; the ledger cannot. Designing one consistency posture for the whole system is what makes this problem look unsolvable.

What a strong answer adds

Noting that the detection is the hard part: a partition and a regional outage look identical, and automated failover triggered by the wrong one is how you get split brain. Prefer human confirmation for cross-region promotion, keep automatic failover in-region, and use fencing so a deposed primary's writes are rejected regardless.