Multi-region is a consistency decision wearing an infrastructure costume

#The question that gets skipped

Multi-region projects usually start with infrastructure: replicate the database, put a global load balancer in front, deploy to both. Then somebody asks what happens when a user in one region writes while the link between regions is down, and the project stops for a month.

That question is the project. Everything else is configuration.

#The constraint

During a partition you can accept the write and risk divergence, or refuse it and stay consistent. You cannot have both, and this has been formally stated for more than twenty years [1].

The more useful framing is Abadi's, which notes that partitions are rare while latency is constant [2]. Even with no partition, a write that must be acknowledged by another region pays the round trip. So the real decision has two parts: what happens during a partition, and what latency you accept the rest of the time.

#Three shapes that work

One writable region. All writes go to a primary, other regions serve reads from replicas. Simple, consistent, and writes from far away are slow. This is the right answer far more often than it is chosen, because it is unglamorous.

Partitioned by tenant. Each customer has a home region and writes there. There is no cross-region write path for ordinary operations, so there is no cross-region consistency problem. Reporting across all tenants becomes a batch job, which is usually acceptable. This is the design I have used most.

Genuinely multi-writer. Requires either synchronised clocks and consensus, which is what Spanner does with hardware support [3], or data types whose concurrent updates merge deterministically [5]. Both are real and both constrain your data model substantially. Choosing this without knowing which of the two you are doing is how projects end up with last-write-wins and silent data loss.

#What eventual consistency means in a product

Eventual consistency is a systems property with product consequences [4]. A user updates their profile and sees the old value on the next screen. A support agent sees a different balance from the customer. Two operators approve the same request because neither saw the other.

Some of those are fine and some are unacceptable, and which is which is a product judgement rather than an engineering one. The engineering work is to make the window visible and bounded so that the product can decide.

#The failover nobody tests

Failover is a procedure, and an untested procedure is a hypothesis. The specific things that go wrong are the ones you cannot reason about from a diagram: DNS caches outlive their time to live, connection pools hold addresses that no longer serve, and the promotion of a replica takes long enough that clients have given up.

If you have not run the failover, you do not have one.