If two devices edit the same record while offline and both sync later, how would a last-write-wins strategy resolve the conflict, and what are its downsides?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Assesses understanding of conflict resolution: how last-write-wins works, when it's acceptable, and the data-loss and clock-skew pitfalls it introduces.

What to say

• Explain that last-write-wins compares a timestamp (or version) on each change and keeps the most recent one, discarding the older edit.
• Call out the main downside: the losing edit is silently dropped, so a real user change can be lost, which is fine for low-stakes single-user data but bad for collaborative or critical fields.
• Flag that it depends on reliable ordering, and device clocks drift, so naive wall-clock timestamps can pick the wrong winner; a server-assigned timestamp or a logical/version counter is more trustworthy.

What to avoid

• Treating last-write-wins as always correct without acknowledging it silently loses data.
• Trusting the device's local clock for ordering and ignoring clock skew between devices.
• Claiming there's only one conflict strategy, with no awareness of server-wins, field-level merge, or CRDTs as alternatives for collaborative data.

Example answers

Strong: Last-write-wins attaches a timestamp or version to each edit and keeps whichever is newer, dropping the other. The risk is silent data loss: one user's change just disappears. It's acceptable for a single-user setting like a profile preference, but for shared data I'd prefer field-level merge or a server-assigned timestamp, because device clocks drift and a local wall-clock can crown the wrong winner.

Weak: Last-write-wins just keeps the latest change, which is what you want anyway since the newest data is the most correct. I'd compare the timestamps from each device and keep the bigger one.