Conflict resolution offline-first app interview

Once you allow offline edits, conflicts are inevitable. Interviewers ask how you reconcile them without silently losing a user's work.

The strategies

The simplest is last-writer-wins using a timestamp or version, which is easy but can discard a valid edit. Per-field merging keeps non-overlapping changes from both devices and only conflicts on the same field. For richer cases, version vectors or CRDTs detect and merge concurrent edits deterministically. Each trades simplicity against how much work it preserves.

Choosing and communicating

Pick the strategy to fit the data: last-writer-wins for low-stakes settings, field merges for documents, stronger schemes for collaborative editing. Attach a version to each entity so the server can detect a conflict rather than blindly overwrite, and decide when to resolve automatically versus prompt the user. Being honest that some policies lose data is the senior signal.

Go deeper than a summary

Share Your Screen works topics like this through in full: 75 solved Swift problems with tests, 9 real case studies, and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.

Get the book

Frequently asked

What is last-writer-wins and its downside?

The most recent write by timestamp or version overwrites the other. It is simple but can silently discard a legitimate concurrent edit.

How does the server detect a conflict?

Each entity carries a version or vector; if an incoming write is based on an older version than the server holds, it is a conflict to merge or reject rather than overwrite.