Offline Sync Is a Conflict Resolution Problem, Not a Storage Problem
Key takeaway: Storing data locally for offline use is the easy part; the hard part is synchronising it back to the server and deciding what happens when the same data was changed in two places — offline sync is fundamentally a conflict resolution problem, and getting the conflict strategy right is what determines whether the feature works.
Why Storage Is Not the Hard Part
The first step of offline sync — storing data locally so the app can work without a connection — is relatively straightforward. The app saves the data it needs to the device, lets the user work with it, and queues the changes to be sent to the server when the connection returns. This part is well understood and mostly a matter of implementation.
The hard part is what happens when the connection returns and the queued changes need to be synchronised with the server. If the same data was changed on the device while offline and also changed on the server by someone else, the two versions conflict, and the app has to decide what to do — which version wins, or how to merge them. This is the conflict resolution problem, and it is where offline sync gets genuinely difficult.
The Conflict Resolution Strategies
| Strategy | How it works | Trade-off |
|---|---|---|
| Last write wins | The most recent change wins | Simple, but can silently lose data |
| Server wins | The server version wins | Simple, but can lose offline changes |
| Client wins | The offline version wins | Simple, but can overwrite server changes |
| Merge | Combine the two versions | Preserves data, but complex |
| Ask the user | Present the conflict for a decision | Correct, but requires user effort |
The simplest strategies — last write wins, server wins, client wins — are easy to implement and are fine when conflicts are rare or when losing one version is acceptable. They are a problem when conflicts are common and when silently losing a user’s changes is unacceptable, because the user may not even know their change was discarded.
Why the Strategy Depends on the Data
The right conflict strategy depends on the nature of the data and how it is used. For data where conflicts are rare and losing a version is acceptable — a note that is usually edited by one person — a simple strategy like last write wins may be fine. For data where conflicts are common and losing changes is unacceptable — a collaborative document, a shared record — a merge or a user-facing conflict resolution is necessary.
The key is to understand the data and its usage patterns and choose the strategy accordingly, rather than defaulting to the simplest strategy for all data, since the cost of a wrong strategy is silently lost or overwritten data.
The Bottom Line
Treat offline sync as a conflict resolution problem, since storing data locally is the easy part and deciding what happens when the same data is changed in two places is the hard part. Choose the conflict strategy based on the nature of the data and how it is used — simple strategies like last write wins for data where conflicts are rare and losing a version is acceptable, and merge or user-facing resolution for data where conflicts are common and losing changes is unacceptable.
