Definition
Conflict resolution is the set of rules a distributed system uses when two or more changes cannot be safely applied as if they happened one after another.
In file sync, this happens when multiple devices edit the same file while disconnected or stale:
laptop edits file based on version 7
phone edits same file based on version 7
server already accepted laptop version 8
phone now uploads a different version 8 candidate
The system must decide whether to reject, merge, overwrite, or preserve both versions.
The Pain That Forces This Concept
The naive approach is last-writer-wins.
That sounds simple until a user loses work. If the phone uploads later and overwrites the laptop edit, the product may appear consistent while silently destroying data.
Other naive behavior is just as bad:
- always reject stale writes and make offline editing painful
- always create duplicates and make folders messy
- try to merge binary files and corrupt them
- hide conflicts until users discover missing work later
Conflict resolution exists because availability, offline use, and user trust pull against each other.
Mental Model
Every write should say what it was based on.
write file_id=f1
base_version=v7
new_manifest=m9
client_mutation_id=c_123
If the server still sees current version v7, the write can advance the file to v8.
If the server sees current version v8 already, the incoming write is concurrent or stale. Now the system needs policy.
How It Works
Common policies:
| Policy | Use Case | Risk |
|---|---|---|
| Last-writer-wins | Low-value metadata or reversible state | Can lose updates |
| Reject stale write | Stronger correctness | Bad offline user experience |
| Conflict copy | Preserve both edits | User must clean up |
| Server merge | Text or structured docs | Merge logic can be wrong |
| Application-specific transform | Collaborative editors | More complex model |
For many file sync products, conflict copy is a practical default:
report.docx
report (Haris's conflicted copy).docx
It may be annoying, but it preserves user work.
Tradeoffs
Conflict policy is product design as much as backend design.
| Goal | Tension |
|---|---|
| Never lose user data | More visible conflicts |
| Keep folders clean | More risk of hidden overwrites |
| Support offline edits | More concurrent versions |
| Make sync automatic | Harder merge semantics |
| Preserve auditability | More version metadata |
A conflict resolver should be conservative when the system cannot prove a merge is safe.
Operational Reality
Operators should monitor:
- conflict creation rate
- stale write rejection rate
- lost-update bug reports
- conflict resolution latency
- client mutation retries
- server merge failures
- version tree depth
- users repeatedly conflicting on the same file
Failure modes:
- A stale client overwrites a newer version.
- Conflict copies are created for idempotent retries.
- Merge logic treats binary files like text.
- Rename conflicts are handled differently from content conflicts.
- A client applies server conflict state out of order.
- Conflict metadata is not visible enough for users to recover.