# Choose a multi-region write model from invariants > Compare single-writer, partitioned-writer, and active-active designs through conflict semantics, failover, latency, RPO, and operating burden. Canonical URL: https://www.devobs.io/articles/multi-region-write-architecture/ By: Amara Okafor Published: 2023-02-21T06:04:02.833Z Updated: 2026-09-05 Section: Comparisons Choose a multi-region write model from business invariants and failure behavior, not from a generic goal of being active-active. A single writer is the safest default for globally ordered facts. Partitioned writers fit data with a stable home. Active-active writes fit operations with explicit, tested conflict semantics. ## Single writer keeps one order All writes go to one region or one consensus leader, while other regions serve reads or standby capacity. This simplifies uniqueness, balances, sequences, and state machines because conflicting writes meet one serialization point. The tradeoff is cross-region write latency and failover procedure. Define who promotes a new writer, how split brain is prevented, what data may be lost, and how clients discover the change. A rapid failover that allows two writers is worse than a slower controlled recovery for financial or authorization data. Managed consensus databases can place replicas across regions while preserving strong write semantics. Google’s [Spanner configuration documentation](https://cloud.google.com/spanner/docs/instance-configurations) describes regional, dual-region, and multi-region placements, voting replicas, quorums, leader regions, and failover behavior. Placement still affects latency and operator decisions even when the service manages replication. ## Partitioned writers give data a home Assign each tenant, account, or key range a home region. Requests route to that writer; other regions can serve suitable reads. Independent partitions fail and move independently, limiting blast radius and avoiding conflicts across most data. The hard invariant is routing. A placement record needs a version, and clients must not write to both old and new homes during migration. Use a drain, replicate, fence, switch, verify sequence. Global operations that span partitions require coordination or an asynchronous business process. Partitioning works when transactions rarely cross homes. It becomes painful when a user’s cart, inventory, payment, and entitlement live in different ownership domains but must commit together. ## Active-active requires a merge rule Multiple regions accept writes to the same logical data. This reduces local write latency and can preserve writes during a regional partition, but conflicts are part of normal operation. “Last write wins” is a policy, not resolution; it can erase a valid update based on clock or arrival order. Azure’s [Cosmos DB global distribution documentation](https://learn.microsoft.com/en-us/azure/cosmos-db/distribute-data-globally) describes multi-region distribution and multiple write regions. Before choosing such a mode, define how each entity merges and which invariants the data store can enforce. Commutative operations such as adding unique set members or incrementing carefully designed counters are easier. Username uniqueness, account balance, inventory decrement, and workflow transitions require coordination, reservation, escrow, or a single owner. If engineers cannot explain the result of two offline regions accepting opposing writes, the entity is not ready for active-active. ## Compare failure semantics For each model, run the same scenarios: loss of the writer, loss of inter-region links, delayed replication, stale routing, client retry after timeout, region recovery, and operator error during failback. Measure recovery time and recovery point for each data class. Include downstream effects. Events may be duplicated or reordered after failover. Search indexes and caches may show a newer state than the primary read path. Idempotency keys need a global or partition-scoped owner. Operator burden is a design input. Document promotion, fencing, reconciliation, and failback. Exercise them. An architecture whose safety depends on a command no one has run is not production ready. Cost belongs in the comparison as well: replicated storage, cross-region transfer, quorum capacity, reconciliation tooling, and continuous drills. Price the steady state and a failure month, then compare that expense with the business loss each model is intended to avoid. Inventory five critical invariants and assign each an owner region or merge rule. If even one invariant needs a total order, begin with a single or partitioned writer for that data and add regional reads. Expand write locality only after failure drills prove the semantics. ## Source references - -