Three Ways to Accept a Write in More Than One Place

Assume three regions — Frankfurt, Virginia, Singapore — with the RTT floors from [[speed-of-light]]: FRA↔IAD about 90 ms, FRA↔SIN about 160 ms, IAD↔SIN about 210 ms. Now put a write in each model and follow it.

Read the table as four independent questions, because they fail independently. A model can have excellent write latency and terrible failover. A model can have no conflicts and still lose data. Teams routinely choose on the latency column alone and are then surprised by the failover column eighteen months later, during the incident that made them look.

One region holds the write lease for the dataset. Everyone else reads locally and forwards writes. This is [[leader-based-replication]] with the leader’s replicas placed across an ocean, and it is the model to beat, because it is the only one where you can state a guarantee in one sentence and have it be true.

Its cost is precisely legible: a user in Singapore writing to a Frankfurt primary waits 160 ms plus processing, on every write, forever. If the interaction is one write per user action, that is fine and nobody complains. If the interaction is a form that autosaves per keystroke, it is unusable, and the fix is not "make the network faster" — it is a different write model or a different interaction.

The failure story is where single-writer earns its complexity. When the writer region is unreachable, writes stop everywhere. That is not a bug; it is the guarantee working — the system is refusing to let a second region create a divergent history. Whether you *want* that refusal is the CAP choice, made concrete, and [[cap-theorem]] is the framing. What you must not do is add "temporary" write capability elsewhere during an incident, because that converts a clean unavailability into a permanent divergence that nobody will reconcile correctly.

Every region accepts writes locally and ships them to the others asynchronously. Write latency is ~2 ms in all regions, region loss requires no failover step, and the model is genuinely the right choice for some data. The bill arrives on the read side and the correctness side.

The conflict window is the replication lag, not "the same instant". Two edits 300 ms apart in different regions are concurrent for conflict purposes if replication takes 400 ms — and users have no intuition for this, so the bug reports say "it overwrote my change" and the logs say everything succeeded. [[write-conflicts]] is the general treatment; the geo-specific point is that the window is *large* and *variable*, and grows exactly when the system is under stress.

What multi-writer cannot do is enforce an invariant that spans regions. A globally unique username, a non-negative balance, an inventory of one hundred seats: none of these survive two regions both saying yes. Systems that appear to manage it are doing one of three things — restricting the invariant to a single owner (which is the third model), pre-splitting the resource so no coordination is needed (escrow, and see [[coordination-avoidance]]), or detecting the violation afterwards and repairing it, which means someone gets a "your username has been changed" email.

Choose multi-writer when the data is naturally append-only, or when a merge function genuinely exists — a shopping cart that unions, a counter that is a [[crdts]]-style sum, a document with operational merge, a set of tags. Choose it deliberately for those, not as a default because the latency column looked good.

Split the keyspace and give each region exclusive authority over its slice. Frankfurt owns the EU tenants; Virginia owns the Americas; Singapore owns APAC. A write to a key lands in its owning region — locally if the user is where their data is, forwarded if not. Within a partition you have single-writer semantics with all of its guarantees; across the system you have local latency for the overwhelming majority of writes.

This is not a compromise between the other two. It is a recognition that most data has a natural home. A user’s account, a tenant’s workspace, an order and its history, a device’s telemetry — these are almost never written by two continents at once. The multi-writer conflict problem is largely an artefact of pretending that a globally-shared dataset exists when what you actually have is millions of small, independently-owned datasets that happened to be stored in one table.

The mechanics are those of [[why-partition]], applied with geography as the partition key’s home rather than as the key itself. You need three things. A directory: something that maps a key to its owning region, replicated everywhere and read on every request — usually cached hard, because a stale directory entry sends a write to the wrong place. An ownership handoff protocol: a user relocates, a region is lost, load rebalances, and a partition must change hands. This is a lease with a fencing token, exactly as in [[leases]] and [[fencing-tokens]], and getting it wrong is how you get two regions believing they own the same key. A cross-partition story: transferring funds between an EU account and a US account touches two owners, and there is no free atomicity there — it is [[cross-partition-operations]] and usually a saga.

The honest costs: the directory is a new globally-consistent thing to run, and it is on the critical path. Homing can be wrong — a user who travels, a tenant with staff on three continents, a "global" admin view that touches every partition. And rebalancing is a real operation with real risk, because it moves authority, not just bytes. But compare that list against "design a merge function for every field in the system and explain to users why their edit vanished", and partitioned ownership looks a great deal better than its reputation.

The final move is to stop asking "what write model does our system use?" A real system uses several, and the split is by invariant.

Billing ledgers want single-writer, because the invariant is arithmetic and a conflict is a financial discrepancy. User profiles want partitioned ownership, because each profile has an obvious owner. Feature-flag configuration wants single-writer with global read replicas, because it is written rarely and read constantly. Activity feeds and audit logs want multi-writer, because they are append-only and merging is trivial. Session state wants regional ownership with no cross-region replication at all — losing it on a region failure is acceptable and much cheaper than replicating it.

Written out that way, the design becomes reviewable. Any table in your system should be able to answer: which region decides, what happens if that region is unreachable, and what merges if two writes race. If a table cannot answer all three, that table is where your next multi-region incident will start.