Offline conflict resolution
Slap yourself if
You think conflicts are rare edge cases that can be solved with ‘last write wins’.
Why this exists
Offline conflict resolution exists because users keep working when the network doesn’t. Multiple divergent histories are inevitable, and pretending there’s a single source of truth until reconnection guarantees data loss or silent corruption.
Mental model
Offline systems don’t pause — they fork. Conflict resolution is about reconciling competing timelines, not picking a winner after the fact.
- The client continues to accept writes while disconnected.
- Local state diverges from the server’s authoritative history.
- Upon reconnection, multiple valid but incompatible updates exist.
- The system must merge, reject, or surface conflicts explicitly.
- Blind last-write-wins overwriting meaningful user work.
- Assuming conflicts only happen on the same field.
- Auto-merging without preserving intent.
- Resolving conflicts invisibly and breaking user trust.
Offline conflict resolution is the process of reconciling divergent client and server histories created during offline operation, preserving user intent without silently discarding valid work.
- Last-write-wins used as a default
- No representation of local versus remote intent
- Conflict handling added only at sync time
- Assuming backend resolution fixes frontend semantics
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.