Concepts
Conflict Resolution
Decide what happens when multiple devices or services change related state concurrently and no single update can safely overwrite the others.
After this, you will understand
How Conflict Resolution helps you see where this idea appears in production systems, what problem forces it, and how to reason about the tradeoffs.
Treat the idea as a definition to memorize.
Real systems force the idea to handle Concurrent Writes, Version Check, and Conflict Copy.
Use the concept to decide what the system guarantees, what it risks, and what it costs to operate.
Think before readingWhere would Conflict Resolution appear in a real production system, and what failure or bottleneck would it help you reason about?
Reading in progress
This page is saved in your local study history so you can continue later.
Concepts Covered
- Concurrent writes
- Lost updates
- Base versions
- Conflict copies
- Server-side merge
- User-visible conflicts
- Last-writer-wins
- Operational repair
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.
Related Topics
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
Used In Systems
System studies where this idea appears in context.
Related Concepts
Core ideas that connect to this topic.
Related Patterns
Reusable architecture moves built from these ideas.