What is a CRDT? Replicated Data Types Explained

A CRDT (conflict-free replicated data type) is a data structure where multiple copies can be edited independently and always merged into a consistent result, without a central server coordinating changes. If two people edit the same document on different devices, even offline, CRDTs guarantee that both edits are preserved and the documents converge to the same state when they reconnect.

The concept was formalized by Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski in their 2011 paper Conflict-free Replicated Data Types, and the research community has been expanding the family of CRDT designs since.

How CRDTs work

Traditional collaborative editing depends on a central server. Every change goes through that server, which decides the final order of operations. If the server goes down, editing stops.

CRDTs flip this model. Each user holds a full copy of the data. Edits happen locally, with no round-trip to a server. When devices reconnect, the copies sync by exchanging their changes, and the CRDT's merge function combines them into an identical result on every device.

This works because CRDTs encode mathematical guarantees into the data structure itself. The merge function that combines two documents has three mathematical properties.

• Commutative means order doesn't matter. Replica A merging with replica B produces the same result as B merging with A.
• Associative means grouping doesn't matter. Merging three replicas in any combination of pairs reaches the same final state.
• Idempotent means applying the same change twice has no additional effect. Duplicate messages during sync are harmless.

These three properties together guarantee that every replica converges to the same result regardless of network delays, message reordering, or retransmission. Modern CRDT libraries like Loro build on these principles and add optimizations for specific data types like rich text, lists, trees, and maps.

Why CRDTs matter

The shift toward local-first software, where your data lives on your device instead of on someone else's server, is making CRDTs increasingly relevant.

Three properties set them apart.

• Offline editing. Make changes without an internet connection and sync when you reconnect.
• No single point of failure. The system keeps working without a central server being online.
• Guaranteed consistency. Every replica converges to the same state by mathematical construction. No "your changes were overwritten" dialogs.

For anyone building tools where multiple people or multiple devices edit the same data, CRDTs replace fragile strategies like locking the document or last-writer-wins with a sound structural guarantee.

CRDTs in practice

CRDTs power real production systems across several categories.

• Collaborative editors. Figma uses CRDT-inspired data structures for its multiplayer design tool. The Zed code editor uses CRDTs as its core replication layer for multi-user editing sessions.
• Distributed databases. Redis uses CRDTs in its Active-Active geo-distributed database to resolve conflicts across data centers. Riak was an early pioneer of the approach.
• Local-first apps. CoCube uses the Loro CRDT library to store every document as a conflict-free replicated data structure. Edits happen locally and sync between devices through binary CRDT snapshots and incremental operations, whether you're online or off.

Modern CRDT libraries

Several open-source CRDT libraries are mature enough for production use.

Yjs has the largest ecosystem and the widest range of editor integrations. Automerge provides a JSON data model that feels natural for application state beyond text. Loro is the newest of the three general-purpose libraries and optimizes for rich text and tree structures, which is why CoCube uses it. Diamond Types is a focused research library for benchmarking plain-text CRDT performance.

CRDTs vs Operational Transformation

Operational Transformation (OT) is the older approach to collaborative editing, most famously used by Google Docs. OT requires a central server to transform and reorder operations. CRDTs don't.

OT is battle-tested for server-centric architectures. CRDTs are the better fit when a central server is a limitation, not a feature, in peer-to-peer systems, offline-capable apps, and local-first tools that put the user's device first.

Related terms

• Local-first software applications that store data on the user's device and sync in the background, often using CRDTs for conflict resolution.
• Eventual consistency a consistency model where all replicas converge to the same state given enough time. CRDTs guarantee this by construction.
• Operational Transformation (OT) an alternative approach for collaborative editing that relies on a central server to order and transform operations.

What to read next

If you want to understand the broader software design philosophy that CRDTs enable, the local-first software article covers the seven ideals of data ownership. If you want to see how CRDTs show up inside CoCube's reactive cell model, the reactive programming post explains the connection. The personal knowledge management pillar is where all of these pieces come together into a system you can use.