CRDT (Conflict-free Replicated Data Type)
Last updated
A CRDT, or Conflict-free Replicated Data Type, is a data structure that multiple devices can update independently and then merge automatically without conflicts. Each replica applies changes locally, and when replicas exchange their states or operations, a defined merge rule guarantees they converge to the same result no matter what order the updates arrive in. CRDTs are a building block for offline-first and collaborative software, where devices edit shared data while disconnected and reconcile later.
How it works
A CRDT is designed so that its merge operation is commutative, associative, and idempotent, meaning updates can arrive in any order, more than once, without breaking convergence. There are two broad families: state-based CRDTs, which ship a whole replica state that is merged with a least-upper-bound function, and operation-based CRDTs, which ship individual operations that every replica applies. Both aim at the same guarantee of strong eventual consistency, where any two replicas that have seen the same set of updates hold the same value.
Common examples include grow-only counters, PN-counters that can decrement, observed-remove sets, and sequence types used for collaborative text editing. Each type encodes enough metadata, such as unique identifiers or version vectors, to resolve concurrent edits deterministically rather than asking a person or a server to pick a winner.
CRDTs solve the merge problem, not the delivery problem. They assume some mechanism carries updates between replicas eventually; they do not themselves move bytes across a radio or a network.
Why it matters
When devices work offline, each one accumulates local changes that must later be reconciled. A naive last-writer-wins approach silently drops edits, and manual conflict resolution does not scale. CRDTs let apps accept writes on every device with no coordination and still guarantee the data ends up consistent, which is why they underpin collaborative editors, local-first note apps, and distributed databases.
The tradeoff is metadata overhead and, for some types, careful garbage collection. In exchange, applications gain availability during partitions and a predictable convergence guarantee that does not depend on a central authority being reachable.
How it relates to Offline Protocol
Offline Protocol is honest about its layer: it is the transport, identity, and discovery layer, not a CRDT database. It provides the multi-transport mesh, DORS, which combines BLE, WiFi Direct, and the internet with automatic failover and up to 8-hop relay, plus Ed25519 OfflineID identity and serverless service discovery. It moves whatever bytes a sync layer hands it, including CRDT states or operations, over encrypted MLS (RFC 9420) sessions.
In other words, a CRDT decides how shared data merges, and Offline Protocol carries those updates between devices when there is no internet. The two are complementary. For a comparison with a sync-focused platform built around this model, see Offline Protocol vs Ditto. The mesh also uses store-and-forward so updates propagate across intermittent links.
Frequently asked questions
What is a CRDT in simple terms?
A CRDT is a data structure that lets many devices edit the same data offline and then merge their changes automatically, with a rule that guarantees every device ends up with the same result regardless of update order.
Is Offline Protocol a CRDT database?
No. Offline Protocol is the transport, identity, and discovery layer. It does not merge data itself; it carries whatever a sync layer, including a CRDT-based one, produces between devices over its mesh.
What are CRDTs used for?
They are used for offline-first and collaborative software such as shared text editors, note apps, and distributed databases, where devices must accept writes while disconnected and reconcile without conflicts later.
