What Is a CRDT?

When two people edit the same document at the same time, or when a mobile app syncs changes after going offline, something has to decide which version wins. Traditional approaches use locks, leader election, or last-write-wins timestamps. Each has drawbacks: locks block collaborators, leaders create single points of failure, and timestamps cause subtle data loss when clocks skew.

Conflict-free Replicated Data Types (CRDTs) offer a different contract. Replicas can apply updates independently, in any order, without coordination—and when they exchange updates, they are guaranteed to converge to the same state. No central server is required for conflict resolution at merge time, though many systems still use a server for persistence or fan-out.

This explainer defines CRDTs, describes the two main families, walks through common data types, and outlines where they help—and where they do not.

The problem CRDTs solve

Distributed systems often replicate data for availability, latency, or offline use. Replicas receive updates at different times and in different orders. Without a merge rule, replicas diverge permanently.

Consider two users editing a shared shopping list offline:

• User A adds "milk"
• User B adds "eggs"
• Both come online and sync

You want both items on the list. A naive last-write-wins merge might keep only one edit. A CRDT-based list merge keeps both additions because the operations commute: order of applying "add milk" and "add eggs" does not change the final set.

CRDTs formalize data types and operations so that merge is associative, commutative, and idempotent, and the result is independent of delivery order (eventual consistency with a strong convergence guarantee).

Strong eventual consistency

CRDT-based systems typically target strong eventual consistency (SEC):

1. Eventual consistency: If no new updates occur, all replicas eventually hold the same state
2. Strong: That converged state is deterministic—any two replicas that have received the same set of updates arrive at identical state, regardless of order

SEC does not mean instantaneous consistency. It means absence of conflict resolution surprises once updates propagate.

Two families: state-based and operation-based

CRDT literature distinguishes two equivalent approaches to achieving the same convergent types.

State-based CRDTs (CvRDTs)

Replicas periodically exchange full state or delta state and merge with a join function. Merge must be commutative, associative, and idempotent.

Example intuition: a G-Counter (grow-only counter) stores a count per replica ID. Merge takes the element-wise maximum of each replica's counts. The total is the sum of those maxima.

State-based CRDTs suit systems where broadcasting full state is affordable or deltas compress well.

Operation-based CRDTs (CmRDTs)

Replicas exchange operations only. The system assumes reliable causal broadcast: if operation A causally precedes B, all replicas deliver A before B. Duplicates are removed; order of concurrent ops does not matter if ops are designed to commute.

Operation-based CRDTs can be more bandwidth-efficient when state is large but each operation is small.

In practice, many libraries hybridize: ops on the wire, merged state in memory.

Common CRDT types

G-Counter and PN-Counter

A G-Counter only increments. Each replica increments its own slot; merge takes max per slot; total value is sum of slots. You cannot decrement.

A PN-Counter pairs two G-Counters (increments and decrements) to allow net increase and decrease while remaining convergent.

Use cases: vote counts, inventory tallies where merge semantics match business rules.

G-Set and OR-Set

A G-Set (grow-only set) adds elements but never removes. Merge is set union.

An OR-Set (observed-remove set) supports add and remove. Removes are tagged with unique identifiers so concurrent add and remove resolve predictably: if one replica removes an element while another re-adds it, the OR-Set semantics define whether the element appears in the merged state.

Use cases: collaborative tag lists, membership sets, todo item collections.

LWW-Register (last-writer-wins register)

Stores a single value with a timestamp (and often a replica ID tie-breaker). Merge keeps the value with the highest timestamp.

Simple but can drop concurrent writes—only one writer's value survives. Some systems use LWW for low-stakes fields; avoid it when every concurrent edit must be preserved.

RGA and sequence CRDTs for text

Text editing requires ordered sequences. CRDTs like RGA (Replicated Growable Array) or YATA assign unique IDs to each character or item in a sequence. Inserts reference positions by ID; concurrent inserts at the "same" position still converge to a deterministic order using ID comparison.

Modern collaborative editors (e.g., systems built on Yjs, Automerge) use sequence CRDTs or related structures so typing latency stays local while merges reconcile edits.

Map CRDTs

A OR-Map or LWW-Map composes CRDTs per key: each map entry might be an OR-Set, a counter, or a nested map. Merge applies per-key merge functions.

Use cases: JSON-like documents with independent fields edited concurrently.

How merge works in practice

Libraries such as Automerge, Yjs, and Diamond Types hide merge mechanics behind document APIs. Typical flow:

1. Each client holds a local replica of the CRDT document
2. Local edits apply immediately (low latency, offline-capable)
3. Changes encode as binary updates or JSON patches
4. Updates sync via WebSocket, peer-to-peer, or store-and-forward
5. Receiving replica merges updates; all participants converge

Developers interact with familiar structures (text, maps, lists) while the library guarantees convergence.

CRDTs vs operational transformation (OT)

Operational Transformation was widely used in collaborative editing (e.g., Google Docs-style systems). OT transforms concurrent operations against each other so they can be reapplied in different orders on a central or semi-central model.

| Aspect | CRDT | OT |
|--------|------|-----|
| Coordination | Designed for peer-to-peer merge | Often needs central server or strict ordering |
| Complexity | Shifted to data structure design | Shifted to transform functions |
| Offline | Natural fit | Harder without replay infrastructure |
| Memory | Metadata per insert (IDs, tombstones) | Varies |

Many new collaborative products choose CRDTs for offline-first and decentralized sync. OT remains in mature systems where infrastructure already exists.

Advantages

Offline-first: Users edit locally; sync reconciles later without manual conflict UI in many cases.

Peer-to-peer potential: No single merge authority required (though practical apps often use servers for auth and backup).

Predictable convergence: Same updates yield same state—easier to reason about than ad hoc merge rules.

Multi-device: Phone, laptop, and server replicas can all apply edits and converge.

Limitations and trade-offs

Metadata overhead: Sequence CRDTs attach unique IDs to content; long-lived documents accumulate tombstones and metadata. Compaction and garbage collection are active research and engineering areas.

Semantic conflicts: CRDTs resolve syntactic conflicts (concurrent ops converge). They do not resolve semantic conflicts (two users editing the same sentence differently). The merged text may contain both edits in an order that reads awkwardly. Human review or higher-level merge policies may still be needed.

Not every data type is a CRDT: Arbitrary business invariants (e.g., "balance must not go negative") are not automatically enforced. You may need validation layers or restricted operation sets.

LWW still loses data: Types that use last-write-wins sacrifice concurrent updates by design.

Testing burden: Convergence properties should be verified with property-based tests and simulations of reordering and duplication.

When to consider CRDTs

CRDTs fit when:

• Multiple writers update the same structure without guaranteed connectivity
• You want automatic merge without a single lock server
• Eventual consistency is acceptable for the product experience
• The data model maps to available CRDT types (counters, sets, maps, text)

Reconsider when:

• Strong consistency and linearizability are mandatory (financial ledger with strict invariants)
• Conflict UI is preferable to automatic merge (some CMS workflows)
• State is huge and merge bandwidth is prohibitive without custom compaction

Garbage collection and compaction

CRDTs that support deletion often retain tombstones—metadata marking removed items so that a late-arriving add does not resurrect deleted content incorrectly. Over months of editing, tombstones and unique IDs accumulate.

Production systems implement compaction or snapshotting:

• Periodically rewrite state to a compact form without tombstones (when causality allows)
• Snapshot document at a version and garbage-collect ops before that version
• Use CRDT libraries that expose save/load with pruning APIs

Ignoring GC leads to growing sync payloads and slower merges. Plan for it in long-lived documents (wikis, design files) from the start.

CRDTs in the wider consistency landscape

CRDTs occupy one point on a spectrum:

• Strong consistency (linearizable reads/writes): single copy or consensus (Raft, Paxos)—simpler reasoning, higher coordination cost
• Eventual consistency without CRDTs: ad hoc merge functions—flexible but easy to get wrong
• SEC with CRDTs: proven convergence for defined types

Choosing CRDTs is choosing to encode merge logic in the data structure rather than in application-specific conflict UI. That trade-off fits collaborative editors and offline caches; it fits poorly when global invariants must hold on every read.

Getting started

For application developers, starting with a maintained library is more practical than implementing CRDTs from scratch:

• Automerge: JSON-like documents, JavaScript and Rust ecosystems
• Yjs: Text and shared types, common in browser editors
• Automerge and Yjs both integrate with various network providers

Read the library's merge semantics for your types. Prototype concurrent edits in tests: duplicate delivery, reversed order, and offline queues.

Summary

A CRDT is a replicated data type whose operations are designed so that replicas merge without conflicts and always reach the same final state. They underpin offline-first apps, collaborative editing, and distributed state without locks. They do not eliminate semantic disagreements or replace all consistency models—but for many multi-writer scenarios, they turn "merge hell" into a solvable engineering problem with clear mathematical guarantees.