Conflict-free Replicated Data Types let you merge concurrent updates without coordination. They power collaborative editing (Figma, Linear), offline-first apps, and globally-replicated counters. The cost: state grows, semantics are restricted to operations that commute.

Advertisement

The core idea

Define operations such that any two replicas, regardless of order they applied operations, converge to the same state. The math: state forms a join-semilattice, operations are lattice elements, merge is the join. Sounds abstract; in practice it's 'pick the right counter design'.

Practical CRDTs

G-Counter (grow-only): each replica owns a counter; total = sum. PN-Counter: two G-counters (P for increments, N for decrements). OR-Set (observed-remove set): adds and removes tagged with unique IDs; merge resolves correctly. RGA, Y.js: ordered sequences for text editing.

Advertisement

Where they win

Collaborative editing: every keystroke merges with concurrent edits, no server-mediated locking. Offline-first mobile apps: users edit on multiple devices and sync without conflicts. Global counters: each region increments independently, sum is exact.

Where they don't

Unique constraints (uniqueness needs coordination). Strong ordering across users (e.g., 'lottery winner is the first click'). Anything with 'no, that operation shouldn't have been allowed' — CRDTs accept all operations; revoke is a different operation, not a rollback.

State growth

OR-Set carries tombstones for removed elements. Y.js carries operation history. Without GC, state grows forever. Production CRDTs need periodic garbage collection synchronized across replicas (often via causal stability).

CRDTs replace consensus for commutative operations. Pick the right one for the data type. Budget GC.