CRDT
Conflict-free Replicated Data Type: a data structure that replicas can update independently and merge deterministically without coordination. Powers offline-first and collaborative editing (Figma, Linear). Strong eventual consistency without a server round trip.
- Collaborative editing, offline-first, low-latency local edits.
- When a central authority per edit is too slow.
- When you need linearizable/transactional consistency.
- Simple CRUD where server authority is fine.
Definition
A CRDT is a data type whose operations commute, so any two replicas that received the same set of updates converge identically regardless of order. State-based (CvRDT) or operation-based (CmRDT). Examples: G-Counter, LWW-Register, RGA for text.
Why it exists
Coordinating every edit through a central server kills latency and offline support. CRDTs let clients edit locally and merge automatically, enabling real-time collaboration and offline-first apps without manual conflict resolution.
How it works
Each replica applies operations locally; a sync protocol disseminates them. The merge function is associative, commutative, and idempotent, so convergence is guaranteed. Metadata (vector clocks, tombstones) tracks causality; size must be bounded.
Scaling limits
Metadata can grow unbounded (tombstones, clocks) without compaction. Complex CRDTs (rich text) are hard to implement. Semantics can surprise (deletions reappearing). No global ordering/linearizability.
Cost shape
Bandwidth for sync + memory for metadata. Blow-ups: unbounded tombstones and frequent full-state syncs.
Alternatives
- OT (operational transform) — Centralized, needs a server to transform, older approach.
- Last-writer-wins — Simple but loses concurrent edits.
Failure modes
- Unbounded metadata growth.
- Surprising merge semantics.
- Implementation complexity bugs.