CRDTs & Conflict Resolution
The problem
In an eventually consistent, multi-writer system, two replicas can accept conflicting concurrent updates before they sync — someone has to decide how those conflicting versions get merged back into one, ideally without losing data or requiring a human referee for every conflict.
Why now
Distributed consistency models already established that eventual consistency permits temporary disagreement between replicas; algebraic structures already proved that operations with the right properties (associativity, commutativity) can be combined safely in any order — CRDTs are the direct, deliberate application of that algebra to make merging conflicting replicas automatic and always correct.
Mental model
A CRDT is a data structure specifically designed so merging two divergent replicas is a mathematical guarantee, not a guess — because the merge operation is built to be associative, commutative, and idempotent (a semilattice), the same result comes out no matter what order updates are merged in or how many times a merge is retried. This is algebraic-structures' abstract promise, cashed out as an actual, always-correct conflict resolution strategy.
Requires
- Algebraic StructuresMathematical Thinking
A CRDT's correctness guarantee is precisely the semilattice/monoid property already defined there — associative, commutative, idempotent merge — applied specifically to solve replica conflict resolution rather than left as pure theory.
- Distributed Consistency ModelsDistributed Systems
CRDTs are a concrete technique for surviving under eventual consistency's temporary disagreement between replicas; you need that consistency model's tradeoff already understood before a technique for handling its consequences is well-motivated.
Used in
- Collaborative editing tools (Figma, Google Docs-style conflict-free merging)
- Distributed counters and sets in systems like Redis' CRDT-based data types
- Offline-first mobile apps that must merge changes made while disconnected
- Riak and other databases offering CRDT data types natively
Projects
- Implement a grow-only counter CRDT (each replica tracks its own increments; total is the sum across replicas) and demonstrate it merges correctly regardless of merge order
- Implement a simple last-write-wins register CRDT and explain the specific data loss risk it accepts in exchange for simplicity
Examples
- A grow-only counter CRDT lets each replica increment its own slice independently; the merged total is always correct regardless of which replica syncs with which, in what order
- Two users editing the same document offline, then syncing, can have their changes merged automatically by a CRDT-based text structure without a manual conflict-resolution step
Resources
Mastery checklist
- I can explain why associativity, commutativity, and idempotency together guarantee a safe merge
- I can implement a simple CRDT (e.g. a grow-only counter or a last-write-wins register)
- I can explain the tradeoff a CRDT makes (limited operation types) in exchange for automatic conflict resolution
- I can identify a real application (collaborative editing, offline sync) suited to CRDTs