CRDTs (Conflict-Free Replicated Data Types) Vocabulary
Learn the vocabulary of a data structure whose concurrent updates always merge into the same final state.
0 / 5 completed
1 / 5
At standup, a dev mentions a data structure whose concurrent updates from different replicas can always be merged deterministically into the same final state, with no central coordinator needed. What is this data structure called?
A conflict-free replicated data type, or CRDT, is a data structure whose concurrent updates from different replicas can always be merged deterministically into the same final state, with no central coordinator needed to resolve a conflict. Requiring a central coordinator for every merge reintroduces the coordination bottleneck CRDTs are specifically designed to avoid. This coordinator-free merging is what lets a CRDT stay available and mergeable even while replicas are partitioned from each other.
2 / 5
During a design review, the team wants a CRDT's merge operation to satisfy commutativity, associativity, and idempotence, so applying the same set of updates in any order or any number of times still converges to one result. Which capability supports this?
Merge-function algebraic properties, specifically commutativity, associativity, and idempotence, guarantee a CRDT converges to the same result regardless of the order updates arrive in or whether one is applied more than once. A merge function with no such guarantees risks a different final state depending on network timing, defeating the whole point of a CRDT. These properties are the mathematical foundation that makes a CRDT's convergence promise actually hold.
3 / 5
In a code review, a dev notices a counter CRDT tracks separate increment and decrement counts per replica internally, rather than storing one single shared numeric value updated directly by every replica. What does this represent?
A state-based CRDT design tracks separate per-replica counts internally, so merging two replicas' states can always deterministically combine them without losing an individual replica's updates. Storing one single shared numeric value updated directly by every replica has no way to merge two diverged copies without a coordinator serializing the updates. This per-replica internal structure is what lets a counter CRDT merge correctly even after replicas have been offline and diverged independently.
4 / 5
An incident report shows a naive shared counter, updated directly by multiple replicas during a network partition, ended up with a final value that silently lost several increments once the partition healed and the replicas' states were reconciled. What practice would prevent this?
Using a counter CRDT that tracks per-replica state internally ensures a merge after a partition heals combines every replica's updates without silently dropping any of them. A single shared numeric value updated directly by multiple replicas has no principled way to reconcile two diverged copies, risking exactly the lost increments this incident describes. This per-replica tracking is precisely the property that makes a CRDT resilient to a network partition.
5 / 5
During a PR review, a teammate asks why the team adopts a CRDT for a replicated counter instead of a single shared numeric value updated directly and synchronized after the fact. What is the reasoning?
A single shared value updated directly by multiple replicas has no principled way to merge two diverged copies once they've been updated independently during a partition. A CRDT's per-replica tracked state guarantees a deterministic, lossless merge precisely because its merge function is commutative, associative, and idempotent by design. The tradeoff is the added memory and complexity of tracking richer internal state than a plain shared value would need.