Active-Active Replication

Active-active replication is a database architecture where two or more database nodes, often in geographically separate regions, can each accept write operations simultaneously, with changes propagated between all nodes so that every node eventually reflects every write — in contrast to a primary-replica setup where only one node can accept writes at a time.

Why It’s Used

Active-active designs solve two problems that a single-writer architecture can’t: they let an application serve users from the geographically nearest database node with low write latency (rather than routing every write across a continent to a single primary), and they eliminate the failover delay of a primary-replica setup, since there’s no single primary whose failure requires promoting a standby — if one node goes down, the others continue accepting writes without interruption.

The Core Challenge: Write Conflicts

Allowing simultaneous writes to multiple nodes introduces the possibility of conflicting writes — two nodes each independently modifying the same record before learning about the other’s change. Active-active systems need an explicit conflict resolution strategy to handle this: common approaches include “last write wins” (using timestamps to pick a winner, accepting that the losing write is silently discarded), conflict-free replicated data types (CRDTs, data structures mathematically designed so concurrent updates can always be merged without conflict), or application-level conflict resolution logic tailored to the specific data model.

Where It’s Used

Databases purpose-built for this pattern — Cassandra, CockroachDB, and Cosmos DB in certain configurations — handle conflict resolution as a core part of their design. Active-active replication is generally reserved for use cases where global write latency or continuous availability genuinely outweighs the added complexity of conflict handling, since simpler primary-replica or Multi-AZ patterns are sufficient — and considerably easier to reason about — for workloads that don’t need writes accepted in multiple regions simultaneously.

CRDTs as a Conflict-Free Alternative

Conflict-free replicated data types (CRDTs) take a fundamentally different approach to the conflict problem than last-write-wins: rather than resolving conflicts after they occur, CRDTs are data structures mathematically designed so that any two independently made concurrent updates can always be merged into a single, consistent result without data loss or the need for a resolution policy at all — a counter that only increments, for example, can be safely incremented concurrently on multiple nodes and merged by simply summing the increments. This mathematical guarantee makes CRDTs attractive for specific data types (counters, sets, certain collaborative editing scenarios) where the underlying operation genuinely commutes, though not every kind of data can be modeled as a CRDT, which is why last-write-wins and application-level conflict resolution remain necessary for the many cases CRDTs don’t cleanly cover.