Skip to content

Last-Write-Wins Register

Conflict-resolution method — instantiates Shared-State Consistency Contract Design

Resolves concurrent writes to a single value by keeping the one with the highest version stamp and discarding the rest — deterministic convergence at the cost of silently dropping the losers.

A Last-Write-Wins (LWW) Register is the simplest possible conflict-resolution rule for a single value: every write carries a version stamp (usually a timestamp), and when two writes to the same key conflict, the one with the higher stamp wins and the other is thrown away. Its distinguishing property — the thing that makes it this mechanism and not a general merge — is that it resolves conflict by total discard: it always converges to exactly one of the written values, never a combination, so it is trivially convergent but structurally lossy. It is the deliberate choice to accept losing data in exchange for a dead-simple, always-agreeing rule.

Example

A couple share control of a smart thermostat. From the kitchen, one sets it to 70°F; ten seconds later, from the bedroom, the other sets 68°F — but both phones were briefly offline and sync only afterward. The device shadow uses an LWW register on "setpoint": each write is tagged with a stamp, and on reconnection the store keeps the higher-stamped write — 68°F — and discards 70°F. For a thermostat this is exactly right: you want one setpoint, not an average or a set of both, and "the most recent instruction wins" matches human intuition. The register makes that resolution automatic and identical on every device, with no prompt and no merge.

How it works

The distinctive move is that resolution is a comparison of version tokens, not a merge of content. Each write is (value, stamp); a read returns the value with the maximum stamp seen; replicas converge because "take the max-stamped write" is commutative, associative, and idempotent (the LWW-register is the degenerate CRDT). Everything hinges on the stamp's ordering: with a wall-clock timestamp and skewed clocks, "last" means "last according to a possibly-wrong clock," so a genuinely later write can lose to an earlier one that a fast clock happened to stamp higher.

Tuning parameters

  • Stamp source — wall-clock timestamp (intuitive, clock-skew-prone) vs. a hybrid logical clock or version stamp (causality-safe, less human-meaningful). This dial decides how often the "wrong" write wins.
  • Tie-break rule — a deterministic breaker (for example, higher replica id) when stamps are equal, so all replicas still converge to the same choice.
  • Granularity — per-field vs. per-record LWW; per-record is simple but lets an update to one field clobber a concurrent update to another, while per-field limits collateral loss.
  • Loser handling — silently drop vs. log or siphon discarded writes for audit and possible recovery.

When it helps, and when it misleads

Its strength is being near-zero cost, trivially convergent, and semantically correct wherever the domain genuinely wants a single latest value — a status, a setpoint, a display name. Its danger is that the loss is silent and invisible: two users make concurrent edits, both receive success responses, and one edit vanishes with no error and no trace.[1] The classic misuse is applying LWW to state where concurrent writes are additive — a shopping cart, a set of collaborators, a counter — where "keep one, drop the other" quietly destroys data the user expected to keep. The discipline is to reserve LWW for values that are genuinely single-valued, and for additive state to reach instead for a merge that keeps both.

How it implements the components

  • conflict_resolution_rule — the mechanism is a conflict-resolution rule: highest stamp wins, losers discarded, deterministically and identically on every replica.
  • version_token — it depends on and compares a per-write version stamp; that token is what defines "last."

It keeps only one value, so it does not merge concurrent updates into a combined state — that is CRDT-Like State Merge's merge policy — and it does not generate the stamps it compares, which come from a clock such as Hybrid Logical Clock or Version Vector.

References

[1] The well-known hazard of last-write-wins under wall-clock stamping is the lost update: with clock skew between nodes, a causally-later write can carry a smaller timestamp and be silently discarded. Stamping with a causality-respecting clock removes the reordering but never the underlying fact that LWW keeps one write and drops the rest. ↩