Practical Demystification of CRDT
summary
Claim: CRDTs solve offline, concurrent sync by putting merge logic in the data type; TomTom uses an OUR-set (Observed Updated Removed) to add updates to CRDT sets, with UUID identifiers and timestamps, implemented as a compact Scala implementation and a Java counterpart, stored and merged in the backend (e.g. nav Cloud with Riak) and optimized by sending diffs; practical limits include tombstone growth, TTL/pruning and the need for deterministic, monotonic timestamping.
AI-written summary · about
chapters (14)
- 0:00Introduction to Nav Cloud
- 1:38Challenges in Synchronization
- 3:33Understanding CRDTs
- 5:58CRDT Practical Examples
- 8:20Data Synchronization Issues
- 10:32CRDTs in Database Systems
- 13:41Exploring Set Implementations
- 18:13Observed-Remove Sets
- 20:41Custom Set Implementation
- 24:04Handling Conflicts and Merging
- 27:16Tombstone Management
- 30:40Bandwidth Optimization
- 32:31Time and Divergence Issues
- 37:00Conclusion and Resources
related talks
36mConflict-Free Replicated Datatypes (CRDT)
48mCRDTs: From sequential to concurrent executions
39mEventually Consistent Data Structures
34mUsing CRDTs Beyond Text Editors
21mCRDTs for Mortals
43mAn Approach For The Internet Of Things
29mAbout Combining Functional Reactive Programming and Replicated Data Types
01h 13mCRDTs: The hard parts