How it works
Conflicts arise when writers update the same value without seeing each other's changes. For example, during a network partition, two regions can both accept a different display name for the same user; after reconnecting, replication must reconcile those values.
With LWW, each write carries a value and an ordering key, commonly a timestamp plus a deterministic tie-breaker such as a writer ID. Every replica keeps the version with the greatest key, regardless of delivery order. The key must uniquely order competing writes, and replication must preserve it rather than assign a new timestamp on arrival.
The word 'last' means greatest ordering key, not necessarily latest in real time or latest user intent. If one writer's clock is ahead, its earlier update can defeat a later update from another writer. Hybrid logical clocks help preserve observed causal order, but they do not reveal which of two concurrent edits the user intended to keep.
Choose the resolution scope explicitly. Whole-record LWW can discard unrelated changes, such as one user changing a phone number while another changes a profile photo. Per-field LWW preserves independent edits but can combine fields into a state that violates application rules.
Deletes need versioned tombstones that participate in the same comparison as writes. Keep them until the recovery and replication protocol makes their removal safe; otherwise, a stale replica can bring deleted data back. Reads and background repair must apply the same resolution rule.
LWW is one policy, not the definition of conflict resolution. Version checks can reject stale saves, version vectors can identify concurrent versions, and applications can preserve siblings or request a user merge. CRDTs provide convergent merge rules for suitable data types, such as sets and counters, without simply choosing one entire value.
A worked example
Two acknowledged profile edits, one surviving value
Two regions accept display-name changes during a 30-second partition. At real time 12:00:00, region A accepts “Maya,” but its clock is 5 seconds fast, so the write carries 12:00:05. At real time 12:00:02, region B accepts “M. Chen” with timestamp 12:00:02. Both clients receive success. After connectivity returns, both replicas compare the original timestamps and keep “Maya,” even though “M. Chen” was submitted later. A writer ID breaks equal-timestamp ties but would not fix this skew. If occasional overwritten display names are acceptable, LWW may be reasonable. For document contents, preserve both revisions or require a base-version check rather than silently discarding one.
Trade-offs to say out loud
- Simple convergence versus lost updates
- A deterministic maximum is cheap to replicate and merge, but losing writes disappear from current state unless history is retained separately.
- Available writes versus immediate agreement
- Accepting writes on both sides of a partition keeps writes available, but LWW only reconciles the resulting divergence later.
- Timestamp convenience versus clock risk
- Physical timestamps are easy to attach, but clock skew or untrusted client timestamps can let an old or malicious write dominate newer values.
- Fine-grained merging versus invariant safety
- Per-field resolution reduces unrelated overwrites but cannot enforce constraints that span fields or records.
- Overwrite semantics versus merge complexity
- Version checks, retained conflicts, and CRDTs can protect more user intent but add coordination, metadata, application logic, or user-facing conflict handling.
- Safe deletion versus retained metadata
- Tombstones prevent stale data from returning, but safe reclamation requires a defined repair horizon and a policy for replicas that return too late.
When to reach for it
- A replicated key-value store must accept writes in multiple regions during partitions, so the design needs an explicit reconciliation policy.
- Offline clients can edit the same file or document, making silent overwrites a product decision rather than just a storage detail.
- A value genuinely has replacement semantics, such as a display preference, and losing a concurrent update is an accepted cost.
- The interviewer asks what happens when updates arrive out of order, clocks disagree, or a deleted record returns from an old replica.
How to bring it up in the interview
- Start with the data's meaning: say whether competing updates may be overwritten, must be merged, or must be rejected. Do not choose LWW merely because the system is eventually consistent.
- Define exactly what 'last' means: timestamp source, tie-breaker, comparison scope, and whether clients can supply ordering metadata. Expect questions about clock skew and retries.
- Walk through a partition with two acknowledged writes, then explain which value survives after repair and what happens to the losing version.
- Separate convergence from correctness: replicas agreeing on an account balance does not prove that all deposits were applied. Expect to defend why the resolution rule preserves the application's requirements.
- Cover the alternative and its cost: conditional writes for stale saves, retained versions for file conflicts, or CRDTs for mergeable state. Follow up with delete handling and safe tombstone cleanup.
Common mistakes
- Defining LWW as 'whichever update arrives last'; different delivery orders would then leave replicas with different values.
- Claiming timestamps establish true real-time order across machines, or that a deterministic tie-breaker fixes clock skew.
- Using LWW to increment counters, reserve inventory, or move money, where discarding a concurrent operation breaks correctness.
- Assuming eventual consistency requires LWW, or that LWW prevents lost updates because all replicas eventually agree.
- Deleting a record without retaining deletion metadata, allowing delayed replication or an old replica to resurrect it.
Where it comes up
Interview questions where conflict resolution and last-write-wins is part of a strong answer, and why.
- Design a distributed key-value storeAccepting writes during partitions requires an explicit conflict policy, deterministic repair, and safe handling of deletions.
- Design Dropbox or Google DriveOffline edits, renames, and deletions require deciding when to preserve conflicting versions instead of silently applying LWW.
- Design Google DocsConcurrent text edits require meaningful merging, making the information loss of whole-document LWW a central design concern.
- Design Wikipedia or NotionConcurrent saves require version checks and durable revision history to prevent silent overwrites of another author's changes.
Questions people ask
What is last-write-wins in a distributed database?
Last-write-wins is a conflict-resolution rule that keeps the value with the greatest ordering key, usually a timestamp with a deterministic tie-breaker. Replicas converge once they receive the same updates, but concurrent updates can be discarded.
Does last-write-wins guarantee the latest write wins?
It guarantees that the greatest ordering key wins, not necessarily the write submitted last in real time. Clock skew and client-generated timestamps can change the winner. Using arrival time independently at each replica is not a safe substitute because replicas can receive updates in different orders.
What are the alternatives to last-write-wins?
Use conditional writes or optimistic locking when stale updates should be rejected rather than silently overwrite current state. Preserve conflicting versions for application or user reconciliation, or use a CRDT when the data has a suitable merge rule. For strict shared invariants, use coordinated updates or transactions rather than relying on conflict resolution after the fact.