Skip to content

CONCEPT Cited by 3 sources

Last-write-wins

What it is

Last-write-wins (LWW) is a conflict-resolution rule for concurrent updates to the same state: if two replicas update the same field, the one with the later timestamp wins.

The timestamp flavour matters:

  • Wall-clock LWW — uses real-world time. Sensitive to clock skew; can lose correct writes from a node whose clock drifts slightly behind.
  • Logical-clock LWW (Lamport / vector / hybrid-logical clocks) — uses a per-node monotonic counter that increments on every event and advances when receiving a higher counter from another node. Resolves causal ordering without depending on wall-clock sync.

Why LWW over consensus

LWW lets you accept writes at any replica without coordination and still converge deterministically. It's the workhorse conflict-resolution rule for CRDT-backed gossip systems and eventually-consistent stores.

Trade-off: the "loser" write is silently overwritten. In shapes where writes rarely actually conflict (one writer per key), LWW is effectively free. In shapes with hot contention, it silently drops data — picks for this case are application specific (CRDTs, CmRDTs, OT, or consensus).

Canonical wiki instance — cr-sqlite / Corrosion

cr-sqlite resolves row-level CRDT merges via LWW using logical timestamps:

"Updates to tables are applied last-write-wins using logical timestamps (that is, causal ordering rather than wall-clock ordering)." — sources/2025-10-22-flyio-corrosion

The shape works at Fly.io because their orchestration model makes workers the source of truth for their own Machines — conflicts between workers are rare by construction.

Second canonical instance — Cassandra USING TIMESTAMP (Netflix Counter)

Netflix's Distributed Counter Abstraction uses Cassandra's USING TIMESTAMP feature to apply predictable LWW semantics to the last-write-timestamp column of the Rollup Store — setting the Cassandra cell timestamp equal to the counter event's event_time:

"Every time a given counter receives a write, we also log a last-write-timestamp as a columnar update in this table. This is done using Cassandra's USING TIMESTAMP feature to predictably apply the Last-Write-Win (LWW) semantics." (Source: sources/2024-11-13-netflix-netflixs-distributed-counter-abstraction)

Two properties fall out:

  1. Deterministic under concurrent writes from multiple regions. Two Rollup servers racing to update last-write-timestamp both map client event-time onto the Cassandra cell-timestamp; the higher one wins regardless of which wall-clock the write physically landed on.
  2. Driven by event_time, not now(). Because the cell timestamp is the event's logical time (client-supplied monotonic), late-arriving older events don't clobber newer values — LWW is aligned with the application's ordering, not the storage engine's.

This is the wall-clock LWW flavour (as opposed to logical clocks like in cr-sqlite) but Netflix bounds the wall-clock skew by rejecting events beyond acceptLimit at the TimeSeries level and measuring sub-millisecond drift on EC2 Nitro. Skew-bounded wall- clock LWW works in that regime; it wouldn't in a truly federated deployment.

Third canonical instance — Netflix Graph Abstraction (load-bearing for async cascade delete + multi-namespace entropy repair)

Netflix's Graph Abstraction inherits LWW from the KV substrate and makes it the load-bearing primitive of two correctness arguments that would otherwise have no obvious fix (Part-I, 2026-05-29):

1. Asynchronous cascade delete vs concurrent updates

A node delete in a high-fanout graph cannot be synchronous (the caller's latency budget can't absorb millions of edge deletes). The cascade runs asynchronously, but a concurrent update could race with the cascade and resurrect deleted state if naive ordering picked the non-delete write. Verbatim:

"Further, to ensure correctness of asynchronous deletes during concurrent updates, the Last-Write-Wins (LWW) conflict resolution mechanism is essential."

Mechanism: every per-edge delete in the cascade carries the delete-intent timestamp T_d, not the wall-clock time of when the cascade fired. LWW guarantees the delete wins against any update with T_u < T_d and yields to any update with T_u > T_d (which the application is responsible for treating as an error since it's an update against a node whose delete intent has already been recorded). (concepts/asynchronous-cascade-delete, patterns/asynchronous-cascade-delete-for-high-fanout-graph-nodes)

2. Kafka entropy repair for multi-namespace writes

The graph layout splits each edge into 3+ KV records (forward link, reverse link, edge property) across separate namespaces. Without distributed transactions, partial-write failures need retry-until-convergence (patterns/kafka-entropy-repair-for-multi-namespace-writes). LWW guarantees a retry that lands after a concurrent newer write loses (newer write preserved); a retry that lands first gets overwritten by the later write. Without LWW, retries could clobber concurrent writes or be clobbered by them in undefined ways.

Why the wiki gets a third LWW canonical instance

Across the three Netflix data abstractions:

Abstraction LWW role
KV DAL LWW on (id, key) writes for hedging / retry safety
Distributed Counter LWW on last-write-timestamp via USING TIMESTAMP
Graph Abstraction LWW for async cascade delete correctness + entropy-repair retry semantics

Each instance shows LWW solving a structurally different correctness problem; the Graph Abstraction face elevates LWW from a hedging-safety primitive to the core invariant that makes asynchronous deletion in a graph store correct.

Seen in

Last updated · 542 distilled / 1,571 read