Offline support usually gets scoped as a caching problem: store data locally, queue writes, replay them when connectivity returns. That part is a week of work. The part that is not scoped is conflict resolution, and it is where offline-first apps either quietly corrupt data or start showing users merge dialogs they cannot answer.
01The queue is not the hard part
Writing to a local store and replaying on reconnect is well-trodden. The complexity appears the moment two clients can modify the same record while partitioned, because the server now receives two edits that both claim to be based on the same original.
Last-write-wins is the default that everyone ships first. It is not a strategy, it is the absence of one - it silently discards whichever edit arrived second, and the user who lost their work gets no signal.
Whether that matters depends entirely on your data. For a read-mostly app with per-user records, last-write-wins is genuinely fine. For anything collaborative or field-operational, it will lose real work.
02Choosing a resolution strategy
The strategy should follow the data shape, and different entities in the same app can use different ones.
| Strategy | Fits | Cost |
|---|---|---|
| Last-write-wins | Single-user records, preferences | Silent data loss when assumption breaks |
| Field-level merge | Forms where users edit different fields | Needs per-field timestamps, more storage |
| Append-only log | Events, readings, audit trails | No conflicts by construction; changes the model |
| CRDT | Collaborative text and lists | Library dependency, larger payloads, real complexity |
| Explicit user resolution | Rare, high-value conflicts | Users cannot usually answer the question |
03The bugs that only appear in the field
Offline bugs are hard to reproduce because they require a specific interleaving of network state, which is precisely what your test environment lacks.
Clock skew is the most common: devices disagree about time, so any timestamp-based resolution picks the wrong winner when a phone's clock is off. Use server-assigned versions or logical clocks rather than device time for ordering.
Partial sync is second. A replay that fails halfway leaves some writes applied and some not, and a naive retry re-applies the first batch. Every queued write needs an idempotency key so the server can safely receive it twice.
Third is queue growth. A device offline for a week accumulates writes that no longer make sense - edits to records that were deleted server-side, or a queue large enough that replay times out. Decide the expiry policy before you ship, not after a support ticket.
- Assign versions server-side; never order by device clock.
- Give every queued mutation an idempotency key and make the server deduplicate.
- Cap queue age and size, and define what happens when the cap is hit.
- Test with a real device in airplane mode, not a network throttle in the simulator.
- Log sync failures to your backend, because the user will not report them.
04What to build first
Ship read-only offline before write offline. Cached reads deliver most of the perceived benefit with none of the conflict surface, and it lets you learn your actual connectivity patterns before committing to a merge strategy.
When you do add writes, start with the narrowest set of entities that genuinely need it. Offline-everything is a much larger commitment than teams expect, and most apps need offline for one or two workflows rather than the whole surface.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer