Conflict-Free Replicated Data Types
If every update is commutative and idempotent, replicas that receive the same set of updates in any order end in the same state, and no coordination is needed at write time. The cost is that the merge rule, not the application, decides what concurrent edits mean.
What a learner can do afterwards
- Say what a merge function has to satisfy for replicas to converge
- Design a counter or a set that converges, and state what its merge does with a concurrent add and remove
- Name a case where automatic convergence produces a state no user intended
1 · Read
Replicas accept writes without coordinating, then swap updates and merge. If every update path is commutative, associative, and idempotent, all replicas that saw the same updates end in the same state no matter the arrival order. Order stops mattering because the merge erases it.
A shared counter gives each replica its own slot. Replica A records 2 adds in its slot and replica B records 3 in its own. Merging takes both slots, so every replica shows 5. A resent update changes nothing, since each slot keeps its highest seen value.
Sets are harder because add and remove of the same element can race. The merge rule must pick: add-wins keeps the element, remove-wins drops it. Both replicas reach the same answer, but the rule chose it, not the users.
Agreement is not intent. With a concurrent add and remove, the merge produces a state mechanically, and it may surprise everyone involved. Use this design where that surprise is harmless, and coordinate where the exact outcome matters.
Order-independent merges converge replicas, but the rule, not the users, settles races.
2 · Watch
Take it off screen
Where it sits
This opens up
Nothing builds on it yet.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.