CRDTs
Conflict-free Replicated Data Types — data structures that merge concurrent edits from disconnected replicas automatically, always, into a consistent state, with no coordination server and no conflict-resolution code (the field’s reference site, captured: clippings/crdt-tech.md).
The problem they solve: when data lives on multiple replicas (devices, databases, collaborators), you get exactly two options —
- Strongly consistent replication: replicas coordinate before applying changes. You get serializability/linearizability, but CAP says a disconnected replica can’t accept writes at all — and coordination costs latency on every write.
- Optimistic replication: any replica accepts writes anytime, offline included. Maximum performance and availability — but concurrent edits conflict, and something must resolve them.
CRDTs are the completion of the second path: the merge is the data structure. Mathematical properties (commutativity, associativity, idempotence — the merge forms a join semilattice over states) guarantee that replicas converge to the same state no matter what order messages arrive in, and no merge ever fails. Decentralized by construction: unlike Google Docs/Trello/Figma, nothing needs to flow through a server.
The two families
- State-based (CvRDT): replicas exchange entire states; merge = least-upper-bound in the semilattice. Simple, tolerant of message loss; chatty for big states. Delta-CRDTs fix the chattiness by shipping state deltas.
- Operation-based (OpCRDT): replicas broadcast operations; merge = applying ops, safe in any delivery order if the transport is reliable (at-least-once + causal ordering). Smaller messages; stricter transport.
And the lineage inside: counters (G-Counter, PN-Counter) → registers (LWW, MV) → sets (OR-Set, “add-wins”) → text/sequence CRDTs (the hard one — RGA, Yjs/YATA, Automerge) which turned the theory into collaborative editors.
Where they already live in the vault
- garage (OSS) — Deuxfleurs’ geo-distributed S3-compatible object store for small self-hosters: CRDT-based weak-consistency replication (dynamo-style, choose availability over consistency across links).
- uncloud (OSS) — uses corrosion (Superfly’s CRDT-based distributed SQLite) to share cluster state between machines — gossip instead of a control-plane database.
- The Embedded databases → local-first thread: CRDT sync is what makes “the client owns the data, sync is a feature” actually work offline (the Optimistic-replication bullet list on crdt.tech is literally the local-first app story).
The pattern worth remembering for homelab-scale distributed state: when a quorum is too heavy, convergence is enough — corrosion-style gossip of cluster state beats a HA etcd for the failure modes that matter at 3 nodes.
Related: High Availability (the consistency/availability trade CRDTs navigate) · Embedded databases (local-first kin) · Kubernetes Operators (state reconciliation’s non-CRDT cousin — desired-state convergence from a controller vs mathematical convergence from a merge) · papers: Preguiça/Baquero/Shapiro 2018 (arxiv 1805.06358), Shapiro et al. 2011