Mobile synchronization
Mobile Data Synchronization Design
A reliable sync engine makes duplicates, delay and disconnection ordinary rather than exceptional.
Short answer
What matters most
Mobile data synchronization needs stable operation identifiers, idempotent server handling, explicit ordering and a conflict policy tied to the product domain. Store pending mutations durably before sending. Retry transient failures with bounded backoff and stop on permanent validation or authorization errors. Record server revisions or cursors so incremental pulls can be resumed. Do not assume timestamps from different devices are trustworthy. Expose sync state so the UI can distinguish local success from remote acknowledgement. Background execution improves progress but foreground launches and user actions must also reconcile. Measure queue age, retry count, conflict rate and time since successful sync.
Separate push and pull
Local mutations and remote changes have different failure modes. Model each explicitly, then define how acknowledgement advances local state.
- Durable operation ID
- Idempotency key
- Client sequence or dependency
- Server revision cursor
- Retry classification
- Conflict resolution result
Choose conflict rules by meaning
Last-write-wins is simple but can silently destroy intent. Field-level merge helps some documents. Server authority is appropriate for protected state. Manual resolution is necessary when neither side can safely win.
State the rule per entity rather than promising one universal algorithm.
Make sync observable
Log operations without leaking private content. Track queue age and permanent failures. Give support enough correlation data to explain why one device appears stale.
In an interview, observability proves the design can be operated after launch.
