What is sync and conflict resolution?
When an app works offline, the same record can change in two places — on the device and on the server, or on two devices. Sync reconciles those changes, and conflict resolution decides what happens when they disagree. It is the hardest part of offline-first.
Why it matters
Naive sync silently loses data: one device's edit overwrites another's, and the user never knows. Getting reconciliation right is what makes an offline app trustworthy. It is genuinely hard, which is exactly why understanding the strategies is valuable and interview-worthy.
What to learn
- Why conflicts arise with offline edits
- Last-write-wins and its data-loss risk
- Per-field merging
- Conflict-free replicated data types (CRDTs) at a high level
- Server timestamps and versioning
- Detecting conflicts on sync
- Surfacing unresolvable conflicts to the user
Common pitfall
Defaulting to last-write-wins without realizing it silently discards the other edit. If two devices change a record offline, the later sync simply erases the earlier change, and nobody is told. Choose a resolution strategy deliberately — field-level merge, versioning, or user prompt — based on how costly losing an edit is.
Resources
Primary (free):
- TanStack Query — Mutations & offline · docs
- CRDT — Introduction · docs
- Martin Kleppmann — CRDTs · video
Practice
For a record that can be edited offline on two devices, design a sync strategy: decide between last-write-wins, field merge, or prompting the user, and justify it by how bad losing an edit would be. Implement detection using a version or timestamp. Done when a conflicting edit is detected rather than silently lost.
Outcomes
- Explain why offline edits create conflicts.
- Compare last-write-wins, merging, and CRDTs.
- Detect conflicts with versions or timestamps.
- Choose a resolution strategy by the cost of losing data.