CRDTs enable conflict-free data synchronization across global regions. Learn how to architect zero-downtime active-active systems for massive scale. Read now.
The Problem With Active-Active Writes
Running a database active-active across regions means every region accepts writes locally, without first coordinating with a distant leader. This removes the round-trip latency that hurts geographically distributed users, and it keeps the system serving traffic even when a whole region drops off the network. The catch is obvious: if two regions accept conflicting writes to the same record at nearly the same moment, something has to reconcile them. Traditional approaches either force a global consensus round on every write, which reintroduces latency and a coordination bottleneck, or they fall back to last-writer-wins, which quietly discards data.
Conflict-free replicated data types, or CRDTs, take a different route. Instead of preventing conflicts through coordination, they define data structures whose merge operation is guaranteed to converge to the same result regardless of the order in which updates arrive.
How CRDTs Make Merges Deterministic
A CRDT works because its merge function is commutative, associative, and idempotent. Commutativity means the order updates arrive in does not change the outcome. Associativity means it does not matter how you group them. Idempotency means applying the same update twice is harmless, which is what lets you retry and re-deliver messages safely across an unreliable network. Any two replicas that have seen the same set of updates will hold identical state, even if they saw those updates in different orders or received some of them more than once.
These properties are the whole point. They let each region apply local writes immediately and gossip them to peers asynchronously, confident that everyone will settle on the same answer once the updates propagate. Common building blocks include:
- Counters that track increments and decrements per replica, so concurrent bumps all add up instead of overwriting.
- Grow-only and add-remove sets that merge membership without losing entries.
- Registers and maps that carry causal metadata so concurrent edits can be surfaced or resolved by a defined rule rather than silently dropped.
Architecting for Zero-Downtime Scale
To build an active-active system on CRDTs, treat each region as a fully independent write target backed by asynchronous replication. Clients route to the nearest region, get an immediate local acknowledgment, and the write flows outward in the background. Because convergence does not depend on any single coordinator, you can add regions, lose regions, or partition the network without halting writes. When a partition heals, the replicas exchange the updates they missed and merge back to a consistent state on their own.
The tradeoff to design around is that you are choosing availability and low latency over strong consistency. Reads in one region may briefly lag writes made elsewhere, so the model fits workloads that tolerate eventual consistency: collaborative editing, presence and activity feeds, shopping carts, counters, and configuration state. It fits poorly where a single global invariant must hold instantly, such as enforcing a unique constraint or preventing a balance from going negative.
Practical Guidance
Start by mapping each piece of your data to a CRDT whose merge semantics match the real business rule, rather than forcing everything into last-writer-wins. Keep the metadata that CRDTs carry under control: some types accumulate tombstones or per-replica history, so plan for compaction and bounded growth. Test convergence explicitly by replaying updates in random orders and with duplicates, and verify that partitioned replicas reunite to the same state. Done deliberately, CRDTs give you global write availability without a coordinator in the hot path.