Convergence Without Coordination

A conflict-free replicated data type is designed so that its merge operation is commutative, associative and idempotent. Any replica receiving the same set of updates — in any order, with duplicates — arrives at the same state as every other. No coordination, no locking, no server deciding.

That is a strong guarantee and it is bought by constraining what the data type can be. A counter that only increases converges trivially. A set that supports adds and removes needs additional machinery — usually tombstones or unique tags — to distinguish "removed" from "not yet seen", and those accumulate.

The two costs are worth stating plainly. Metadata growth: tombstones and version information persist, so the state is larger than the data it represents and requires periodic compaction that itself needs coordination. And convergence is not correctness: two replicas will agree, and the value they agree on may not be what the user meant. Concurrent removal and update of the same element resolves according to the type's rules, and those rules embody a semantic choice.

The right use is collaborative editing and offline-tolerant shared state, where the alternative is losing edits. The wrong use is anything requiring a global invariant — an inventory count that must not go negative cannot be maintained without coordination, and no data type changes that.