CRDTs keep replicas in sync without locks

CRDTs let distributed apps accept concurrent writes and still converge without coordination.

Conflict-free replicated data types, or CRDTs, are a family of data structures built for distributed systems that cannot afford to stop and ask permission before every write. The idea is simple: let each replica accept updates locally, then merge those changes later in a way that always converges.

The Wikipedia article says the concept was formally defined in 2011 by Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. It also points to real deployments in Redis, Riak, and Azure Cosmos DB.

Why CRDTs matter in distributed systems

Distributed software breaks in boring ways. Two users edit the same object, two servers accept writes at the same time, and the system has to decide which value survives. Traditional coordination can solve that, but coordination adds latency, coupling, and failure modes that are painful when networks are slow or unreliable.

CRDTs take a different route. They allow concurrent updates, then define merge rules that make those updates safe to combine later. If the data type is designed correctly, replicas can disagree for a while and still settle on the same result.

That makes CRDTs a natural fit for offline-first apps, collaborative editing, chat systems, and mobile software that reconnects after long gaps. The article also notes that optimistic replication becomes practical when the data structure itself can absorb conflicts without human intervention.

• Each replica can accept writes locally.
• Replicas do not need constant coordination.
• Merge rules are built into the data type.
• All replicas eventually converge on the same state.

Two families, two tradeoffs

CRDTs come in two main forms: state-based CRDTs and operation-based CRDTs. Both aim for strong eventual consistency, but they move data around in different ways and place different demands on the network.

State-based CRDTs, also called CvRDTs, send full local state to other replicas. Each replica merges incoming state with its own using a function that must be commutative, associative, and idempotent. In plain English, order and duplication cannot break the result.

Operation-based CRDTs, also called CmRDTs, send the update operations themselves instead of the whole state. That usually means less bandwidth, but the transport layer has to do more work: operations must arrive without duplication and in causal order.

“The merge function should compute the join for any pair of replica states, and should form a semilattice with the initial state as the neutral element.”

That line from the Wikipedia article captures the math behind the whole idea. The implementation details can vary, but the contract stays the same: the merge has to be safe even when messages arrive late, twice, or out of order.

• State-based CRDTs are easier to design and usually only need gossip-style propagation.
• Operation-based CRDTs send smaller updates, which helps when state is large and writes are relatively rare.
• State-based designs can waste bandwidth by shipping more data than changed.
• Operation-based designs depend more heavily on the messaging layer.

The classic examples explain the model fast

The article’s examples show how CRDT thinking works in practice. A G-Counter is a grow-only counter where each node owns a slot in an array and only increments its own slot. Merging two replicas means taking the maximum value in each slot, then summing the array for the visible count.

The PN-Counter extends that idea by combining two G-Counters, one for increments and one for decrements. That lets the public value move up and down while the internal state still only moves forward monotonically.

Sets show the same pattern. A G-Set allows adds only. A 2P-Set adds a tombstone set so removals win forever. An LWW-Element-Set uses timestamps so the latest write wins. An OR-Set goes further and tracks observed removals in a way that supports more flexible collaboration.

• G-Counter: increment-only counter for distributed tallies.
• PN-Counter: increment and decrement using two monotonic counters.
• G-Set: add-only set with no removals.
• 2P-Set: add plus irreversible removal.
• LWW-Element-Set: timestamp-based conflict resolution.
• OR-Set: remove semantics that preserve more concurrent intent.

Where CRDTs show up in real systems

CRDTs were originally motivated by collaborative text editing and mobile computing, and those are still the clearest use cases. When two people edit the same document while offline, the system needs a way to reconcile both histories without forcing one side to lose work.

They also show up in chat systems, online gambling, and media infrastructure. The article mentions SoundCloud as an example of a platform that used CRDT ideas in audio distribution. That is a useful reminder that CRDTs are not just academic objects; they solve real consistency problems when writes happen all over the place.

For database teams, the appeal is practical. If a service can tolerate temporary divergence and wants to avoid lockstep coordination, CRDTs can reduce the amount of consensus machinery required for certain data shapes. They are especially attractive for counters, sets, flags, and collaboration metadata.

If you want a broader view of distributed data consistency, our related guide on eventual consistency vs. strong consistency pairs well with this topic.

What to watch next

CRDTs are best understood as a design tool, not a universal fix. They work beautifully when the data type can be expressed as monotonic state plus a deterministic merge, and they become awkward when the application needs arbitrary deletes, rich transactions, or strict ordering across many actors.

The practical question for developers is whether a feature really needs coordination or whether it can be modeled as a convergent data type. For counters, presence flags, collaborative annotations, and some document structures, CRDTs often remove more pain than they add.

As distributed apps keep pushing into offline-first and multi-region setups, the teams that understand CRDTs will have an easier time deciding where coordination is worth the cost and where it is just slowing the product down.

The next useful step is to map one real feature in your app, then ask whether its state can be made monotonic. If the answer is yes, you may have a CRDT-shaped problem on your hands.