Skip to content
ROOT
STUB

CRDTs

The pattern: data types that allow concurrent edits to merge deterministically without coordination. Counters that always sum correctly under network partition. Sets that converge regardless of message order. The math (semilattices, commutative ops) guarantees convergence.

The trade-off: coordination-free vs. expressiveness. CRDTs avoid consensus entirely — that’s their power. But not every operation can be expressed as a CRDT (anything order-dependent, anything that requires referential integrity across keys, anything that involves “decrement-only-if-positive”). The right domain: collaborative editing, offline-first apps, replicated counters, presence systems. Wrong domain: bank balances, inventory, anything with strong invariants.

[Deepen Year 2 Phase 8 with the “Comprehensive Study of CRDTs” paper (Shapiro et al.). Where would CRDTs help in your platform? Spoiler: rarely; the domain is collaborative-edit and offline-first.]

  • Consensus — CRDTs are the explicit alternative; pick consensus when you need invariants, CRDTs when you can’t pay coordination cost.
  • Eventual consistency — CRDTs are how you make eventual consistency deterministic instead of last-write-wins.
  • Distributed time — vector clocks and version vectors underpin most CRDT merge functions.
  • Idempotency — CRDT operations are idempotent by construction; that’s why replay is safe.

First touched in Year 2 Phase 8; rarely revisited because the domain is narrow — log it as known and move on.