How would you design offline-first data sync?
Model answer
Offline-first means the local database is the source of truth for the UI. The network only syncs in the background.
Local store. Use SQLite (or a wrapper such as WatermelonDB or Room) and have the UI read from it.
Writes. Save changes locally first and add them to an outbox queue of pending operations. Each operation has a unique id so the server can apply it idempotently on retry.
Sync loop. When the network is available, push the outbox in order, then pull changes since the last sync cursor (a timestamp or version). Use retries with exponential backoff.
Conflicts. Pick a policy per entity: last-write-wins with server timestamps for simple data, field-level merge for documents, or ask the user when data loss is costly.
Details. Show sync status in the UI, soft-delete with tombstones so deletions propagate, and handle schema migrations on the device.
Key points
- Local database is the source of truth for the UI
- Outbox queue of idempotent operations with retry and backoff
- Pull changes using a sync cursor
- Define a conflict resolution policy per entity
Likely follow-ups
- How do deletions sync to other devices?
- How do you handle a schema migration on devices that were offline for weeks?
Common mistakes
- Reading directly from the network and caching as an afterthought
- Retrying non-idempotent operations and creating duplicates