Design offline-first sync and conflict resolution

WHAT THIS TESTS This evaluates distributed-systems thinking applied to mobile: idempotency, deltas, identity, and conflict resolution. There is no single right answer, so the interviewer watches how you reason about trade-offs and edge cases.

A GOOD ANSWER COVERS Make the local database the source of truth for the UI so the app works fully offline. Give every record a stable server-assigned identifier plus a local one, and track per-record sync metadata: a dirty or pending flag, a last-modified timestamp, and ideally a version or revision number. Queue local mutations in an outbox so they survive relaunch, and design the server endpoints to be idempotent so retries are safe. Sync in deltas, not full downloads: send pending local changes, then pull only records changed since a stored change token or updatedAt cursor. Conflicts arise when the same record changed on both sides since the last sync; resolve with a deliberate policy. Last-write-wins by timestamp is simple but can lose data; server-wins or client-wins are predictable but blunt; field-level merge preserves more but is complex; version vectors detect true conflicts. Surface unresolvable conflicts to the user when correctness demands it. Run sync on a background context and handle partial failures with retry and backoff.

COMMON WRONG ANSWERS Assuming the network is reliable or that pushes always succeed. Re-downloading the entire dataset every sync. Ignoring conflicts and silently overwriting. Using local-only ids that collide across devices.

LIKELY FOLLOW-UPS How do you make mutations idempotent? What breaks with last-write-wins? How do you delete safely with tombstones? How do change tokens reduce bandwidth?

ONE CONCRETE EXAMPLE A notes app edits a note offline on two devices. Each note carries a serverId, an updatedAt, and a version. On reconnect, device A pushes its change with the expected version; the server accepts and bumps the version. Device B then pushes with a stale version, the server returns a conflict, and the client merges field-by-field, keeping both the edited title and body where they diverged, rather than blindly overwriting.