CRDTs

## The conflict a CRDT sidesteps In a normal distributed system, when two nodes hold copies of the same mutable value and both are updated independently while disconnected, you get a conflict: which write wins? Traditional systems solve this with: - **locks**; - **consensus protocols** (Raft, Paxos); - **last-writer-wins timestamps** that quietly discard one of the updates. A **CRDT** sidesteps the conflict entirely by designing the data type itself so that `merge` is a well-defined, order-independent operation — no matter which order updates arrive in, how many times a message is duplicated, or which subset of replicas have seen which updates yet, applying the merge function to any set of replica states always produces the same final result. This guarantee is called **strong eventual consistency**: once all replicas have seen the same set of updates (in any order), they hold identical state, with no explicit conflict resolution step and no need for replicas to be online or reachable at the same time. ## How a G-Counter works A **G-Counter** (grow-only counter) is the simplest CRDT and a good vehicle for the general idea. Instead of representing the counter as one shared integer, each replica (A, B, C) owns a private slot in a vector: `{A:0, B:0, C:0}`. 1. When A increments, it only ever bumps its own slot: `{A:1, B:0, C:0}`. 2. The counter's value is always the sum of all slots. 3. To merge two replica states you take the **element-wise maximum** of each slot, not a sum — merging `{A:3,B:1,C:0}` with `{A:2,B:1,C:4}` yields `{A:3,B:1,C:4}`. Because each node only increases its own slot and merge takes the max, no increment is ever lost (max retains the largest count either replica had recorded) and no increment is double-counted (max, not sum, so re-merging the same state twice changes nothing). ## What coordination would cost instead The alternative — shipping every increment to a single owner, or running a consensus protocol so all nodes agree on a serialized order before applying an update — costs a network round trip (or a quorum) per write, and stalls writes during a network partition. That's fine for a bank ledger, but for many practical counters (like counts, shopping carts, presence indicators) you'd rather let every replica accept writes locally, instantly, even fully offline, and reconcile later. CRDTs make that reconciliation mathematically guaranteed to succeed rather than requiring bespoke per-feature conflict logic — the appeal behind **offline-first** apps and **multi-region active-active** designs, where writes never block on other regions being reachable. ## What you give up The cost is **expressiveness and space**. - A G-Counter can only grow — it structurally cannot support decrement (that needs a **PN-Counter**, built from two G-Counters). - More generally, CRDTs only exist for operations whose combined effect can be expressed as a **commutative, associative, idempotent** merge; not every abstract data type admits such a design, and some (like a map with complex nested invariants) require careful structural tricks (unique per-op tags, tombstones) to make merges well-defined. - Complex CRDTs like sets carry per-element metadata that can dwarf the actual payload. ## How teams get it wrong 1. A team new to CRDTs commonly reaches for a plain replicated integer, lets each node add or subtract directly, and **resolves** conflicts with last-writer-wins — this silently drops updates (a concurrent increment from another node just vanishes). 2. Another mistake is merging a G-Counter-shaped vector with **sum** instead of **max**, which double-counts increments every time the same state is re-merged, breaking idempotency. 3. A third failure mode is ignoring the vector's unbounded growth — with high replica churn (autoscaling instances each getting a slot), the vector never shrinks, since a slot can't be safely removed while any other replica might still hold stale state referencing it. ## Where it ships - **Riak KV** (Basho) built native CRDT data types (counters, sets, maps, registers) directly into its replicated key-value store so applications get conflict-free merges without hand-rolling resolution logic. - **Redis Enterprise's CRDB** (Conflict-free Replicated Database) uses CRDTs for active-active geo-replication across regions. - Collaborative editors built on **Automerge** or **Yjs** use CRDT-based sequences so multiple users can type concurrently offline and merge edits deterministically when they reconnect.