Mobile apps in places with unreliable networks taught me more about sync than any tutorial.
The pattern that works for me:
- SQLite is the source of truth for the UI. Reads never wait on the network.
- Writes go to the local table and append an operation to a sync queue.
- A worker drains the queue when connectivity returns, with idempotency keys so retries are safe.
- Conflicts resolve with a version column, and the UI shows the winner with an undo.
The parts people skip:
- The queue needs a max size and a policy for what to drop. Disk is not infinite.
- The server needs to accept out-of-order operations. They will arrive out of order.
- You need a way to test the offline path, or nobody will.
The result is an app that feels fast even when the network is bad, which is most of the time.
How do you handle conflicts on the server side?
Top comments (0)