Active-Active Multi-Region: Who Wins a Write Conflict

Q: What does active-active multi-region actually mean?

Active-active means more than one region accepts live traffic, and usually that more than one region accepts writes. The first part is easy: serving reads from several regions is a replication and routing problem. The second part is the real commitment, because it means two regions can accept different updates to the same record at the same moment. You then need a rule for which update wins, whether that rule is last-writer-wins, a designed merge, or a consensus protocol that rejects one of the writes. Teams that describe active-active as a topology rather than as a write-ownership decision tend to discover the rule only when data goes missing.

Q: How does DynamoDB global tables resolve write conflicts?

It depends on the consistency mode chosen at table creation. In the default multi-Region eventual consistency mode (MREC), concurrent updates to the same item in different regions are resolved by last writer wins on an internal timestamp, so one update is silently discarded; strongly consistent reads are only strong for items last written in the local region, and conditional writes evaluate against the local replica. In multi-Region strong consistency mode (MRSC), generally available since June 2025, writes replicate synchronously to at least one other region before succeeding, and a write to an item being modified elsewhere fails with ReplicatedWriteConflictException for the caller to retry.

Q: What are the limits of DynamoDB multi-Region strong consistency?

According to AWS documentation, an MRSC global table must be deployed in exactly three regions, as three replicas or two replicas plus a witness, and all within one region set such as the US, EU or Asia Pacific set. An existing table must be empty to convert, the mode cannot be changed after creation, replicas cannot be added later, and transactions, Time to Live and local secondary indexes are not supported. Writes and strongly consistent reads have higher latency than MREC because they wait for cross-region replication. In exchange you get a recovery point objective of zero and strongly consistent reads in every region.

Q: Is Aurora DSQL a good default for active-active relational workloads?

Aurora DSQL, generally available since May 2025, offers active-active multi-region clusters with strong consistency, a log-only witness region and 99.999 percent multi-region availability per AWS. It is a strong option for relational entities that genuinely need global invariants. It is not a free default: it uses optimistic concurrency control, so conflicting transactions fail at commit with SQLSTATE 40001 and must be retried, hot keys cause retry storms, every write pays cross-region latency, and it is PostgreSQL-compatible rather than identical. Use it for the entities that need it, and check the compatibility list against your schema and extensions first.

Q: When is last-writer-wins acceptable?

Last-writer-wins is acceptable when losing one of two concurrent updates is harmless or when the data is designed so that concurrent updates do not overlap. Examples include user preferences edited from one device at a time, presence and session state, feature-flag exposure logs, and records naturally partitioned by region so cross-region writes to the same item are rare. It is not acceptable for anything with an invariant: stock levels, account balances, seat counts, single-use coupons or uniqueness constraints. Under last-writer-wins those do not fail loudly — they drift, and the discrepancy is usually found later by reconciliation or finance.

Q: How do you choose between home-region writes and multi-writer replication?

Ask who legitimately writes the entity. If one region users own it — a customer profile, their orders, a merchant settings record — store a home region on the owner, route that owner writes to the home region, serve reads locally from replicas, and re-home through an explicit, fenced failover step if the region fails. That keeps every invariant enforceable in one place at local latency for most users. Choose multi-writer only when the entity is genuinely written from several regions at once and either tolerates last-writer-wins or is designed to merge using deltas, events or CRDT data types.

Q: How much does active-active multi-region cost compared with a single region?

Plan for roughly two to three times the data-tier cost of a single region rather than the cost of a second region idling. Compute in a standby region can scale down, but a replicated data tier cannot: in multi-writer and consensus modes every write consumes write capacity in every replica region, so a three-region strongly consistent table pays for each write three times before any conflict retries, and cross-region replication traffic is billed as data transfer. Observability, secrets, pipelines and on-call also become per-region. The way to control cost is to classify entities and reserve active-active for the ones that need it.

Q: Does a second active region protect against every outage?

No. A second region protects against a regional failure such as the October 2025 US-EAST-1 disruption, where a race condition in DynamoDB DNS management caused an empty regional endpoint record and cascading failures for about fifteen hours. It does not protect against a global control-plane dependency, a bad deployment pushed to both regions, or a corrupting write that replicates faithfully to every region. For those you need staged deployments, point-in-time recovery and immutable backups tested by restore. Replication copies mistakes at the same speed as data, so it is a complement to backups, never a substitute.