CRDT

Picture two people editing the same shopping list while one of them is offline on a train. With a normal database you would have to lock the list or pick one person's version and throw the other's away. A CRDT lets both keep editing their own copy, and when the train reconnects, the two copies merge into one list that contains everyone's changes. Nobody had to ask a server who wins.

The trick is that a CRDT is designed so that its merge operation is commutative, associative, and idempotent. In plain terms: it does not matter what order the changes arrive in, it does not matter how they are grouped, and applying the same change twice does no harm. Because those three properties hold, any two replicas that have seen the same set of updates end up byte-for-byte identical. This guarantee is called strong eventual consistency.

CRDTs come in two flavors. State-based (CvRDT) replicas ship their whole current state and merge it with a join function. Operation-based (CmRDT) replicas ship just the individual operations and replay them. State-based is simpler and tolerant of dropped or duplicated messages; operation-based sends far less data but needs a delivery layer that does not lose messages.

The simplest CRDT is a grow-only counter (G-Counter). Each replica keeps its own slot in a map and only ever increments its own slot. To read the total you sum every slot. To merge two replicas you take the max of each slot. Two nodes can increment at the same time and the sums still add up correctly because each only touches its own number.

Sets are harder because deletion is the enemy of merging. A grow-only set (G-Set) only allows adds. A two-phase set (2P-Set) keeps an add set and a tombstone set, so a removed item can never come back. The widely used OR-Set (Observed-Remove Set) tags every add with a unique id, so concurrent add and remove resolve cleanly: you only remove the exact adds you actually saw, and a fresh add survives.

Collaborative text, the famous Google Docs case, uses sequence CRDTs like RGA or the tree structure behind Yjs and Automerge. Each character gets a unique, densely ordered identifier so two people typing in the same spot interleave deterministically instead of overwriting each other. Causality is tracked with version vectors so every replica knows which updates it has already seen and can ignore duplicates.

CRDTs shine when you need offline-first or multi-leader writes with no central coordinator: collaborative editors, mobile apps that sync when they get signal, multiplayer cursors, shopping carts in a multi-region store. They let every node accept writes immediately, which means low latency and high availability even during a network partition. On the CAP spectrum they pick availability and partition tolerance.

The price is metadata and semantics. Tombstones and unique tags mean the structure can grow larger than the data it holds, and old CRDT designs that never garbage-collected tombstones would bloat forever. Modern libraries compact this, but you still pay more bytes than a plain value would cost.

The deeper trade-off is that automatic merging is not the same as correct business logic. A CRDT guarantees the copies converge, not that the converged result is what a human wanted. Amazon's classic shopping-cart example merges concurrent edits by union, which is why a deleted item could reappear in your cart. If your invariant is something like account balance must never go below zero, a CRDT cannot enforce that across partitions, and you need consensus instead.

Redis Enterprise ships active-active databases built directly on CRDTs (they call them CRDBs). You can run the same database in data centers in Mumbai, Frankfurt, and Virginia, let users write to whichever is closest, and Redis merges the replicas in the background. A counter incremented in two regions at once sums correctly; a string uses last-write-wins keyed by a hybrid clock; a set uses OR-Set semantics.

Concretely, suppose a user in India adds a phone to their cart while a flaky connection causes a retry that also lands in the EU region. Because the cart is an OR-Set, the duplicate add is deduplicated by its tag and the item appears once, not twice. If they remove the phone in one region while a recommendation service adds an accessory in another, both operations survive the merge and no write is silently lost.

This is the same pattern behind Riak's data types, Microsoft's Azure Cosmos DB multi-region writes, and figma-style design tools. The application gets fast local writes everywhere and a single converged truth a few hundred milliseconds later, without ever standing up a leader election or a global lock.