What three algebraic properties must a CRDT's merge function satisfy to guarantee replicas converge, and how does an LWW-Register (last-write-wins register) satisfy them while still having a well-known failure mode?

## The three algebraic properties A merge function used by any CRDT must satisfy three algebraic properties for replicas to be guaranteed to converge to the same state regardless of communication patterns. 1. **Commutativity** means `merge(a, b) = merge(b, a)`: the order in which two states or updates are combined doesn't change the result, which matters because in an asynchronous network there is no guarantee two replicas receive gossip from each other in the same relative order. 2. **Associativity** means `merge(merge(a, b), c) = merge(a, merge(b, c))`: however the merges are grouped or batched — two at a time in any grouping, or all at once — the result is identical, which matters because real systems batch, retry, and reorder merge operations for efficiency and fault tolerance, and the result must not depend on those implementation choices. 3. **Idempotency** means `merge(a, a) = a`: merging a state with itself, or re-merging a state already incorporated, changes nothing, which matters because networks routinely duplicate messages (retries, at-least-once delivery, gossip re-broadcast) and a CRDT must be immune to seeing the same update more than once. ## Why the three add up to convergence Together, these three properties mean the set of possible replica states, ordered by "has observed at least as much as," forms a **join-semilattice**, and merge computes the least upper bound (join) of two states in that lattice. This is the mathematical backbone of **strong eventual consistency**: once two replicas have (directly or transitively, through any path of merges) incorporated the same set of underlying updates, they are in exactly the same state — with no possibility of divergence based on the order, batching, or duplication of how those updates were exchanged. This is what removes the need for consensus or locking: instead of agreeing in real time on a global order of operations, replicas only need the guarantee that whatever order they observe things in, they land in the same place eventually. ## How LWW-Register satisfies them **LWW-Register** (last-write-wins register) is the CRDT for representing a single, arbitrarily-typed value — like "the current display name" or "the current cursor position" — where each write is stamped with a timestamp (a physical clock reading, or more robustly a logical/hybrid clock plus a tie-breaking replica ID to guarantee two writes are never exactly equal). `merge(a, b)` simply returns whichever of the two `(value, timestamp)` pairs has the higher timestamp, with the tie-break applied on exact ties. This satisfies all three properties: - it's **commutative and associative** because "keep the max by timestamp" doesn't depend on evaluation order; - it's **idempotent** because merging a value with an identical copy of itself returns that same value. Reads simply return the current pair's value. ## The well-known failure mode The well-known failure mode is that LWW-Register doesn't actually merge concurrent writes — it **arbitrates** between them, keeping exactly one and permanently discarding the other, the same way a plain last-writer-wins resolution strategy would. If two users concurrently edit a shared "status message" field, only one edit survives; the other is silently gone, with no record a conflict even occurred. This is a legitimate and useful CRDT (it satisfies the three properties and converges deterministically), but "converges deterministically" is a weaker guarantee than "preserves all updates" — engineers sometimes conflate the two and are surprised when LWW-Register "loses" data during genuinely concurrent writes. It's also sensitive to **clock skew**: if replicas' physical clocks aren't reasonably synchronized, an update a human would consider "later" can lose to an update from a replica whose clock is fast, producing outcomes that look wrong even though they're a technically correct, deterministic LWW resolution. ## Where it ships - LWW-Register is the standard building block for individual fields of compound CRDT structures — e.g. a CRDT map is often built as a set of `(key, LWW-Register)` pairs, where each field independently resolves conflicts by timestamp while key membership is handled by a separate structure like an **OR-Set**. - **Riak KV** and **Redis CRDB** both expose an LWW-style register type as one of their native CRDT primitives for exactly this "single scalar field, occasional concurrent writes acceptable to arbitrate" use case. - **Cassandra's** own last-write-wins conflict resolution for cell values follows the identical algebraic pattern, even though Cassandra doesn't market itself as CRDT-based.