Question 5
Offline support and syncing
How would you design a system that works offline and syncs with a backend when connectivity returns?
Follow-ups
- How do you handle conflicts when two devices edit the same record?
Answer outline
Treat local state as authoritative for the UI while offline. Reads come from the local database or cache, and writes go to an outbox: a persisted queue of operations with their payloads and client-generated IDs.
When connectivity returns, drain the outbox with retries. Keep operations on the same entity in order, so an update never reaches the server before the create it depends on.
For example, an app that uploads recorded audio to CloudKit can't send those files while offline. Those uploads wait in the outbox until connectivity returns.
Version fields such as an ETag (entity tag) or an updatedAt timestamp let the server detect a conflict. How to resolve it is a product decision, and four strategies are common:
- 1.Last write wins: the most recent change replaces the record. It's simple, and fine when an occasional lost edit is acceptable.
- 2.Server wins: the server's version is kept, and the client either drops its change or reapplies it on top. Use it when the backend holds the source of truth.
- 3.Merge fields: combine non-overlapping changes at the field level. It works when edits usually touch different properties.
- 4.User picks: surface both versions and let the user choose. Reserve it for high-value content where silent loss isn't acceptable.
Principles
- Show a write in the UI before the server confirms it only where rollback is acceptable, and mark it pending otherwise.
- Idempotent server APIs, where repeating a request changes nothing further, make retries safe when the connection drops before the response arrives.
- Give each logical operation one stable client request ID across retries, so the server returns the same outcome instead of applying it twice.
- Scope offline support deliberately, because not every feature needs to sync.
Follow-up angles
- When two devices edit the same record, each client sends the version it started from. The server compares that with the version it holds. A mismatch is a conflict, and the strategy you chose decides what happens to it.
