Offline-first synchronization

Offline-first synchronization lets clients read and write with **local persistence** while the network is unreliable, then reconcile with the server using queues, retries, conflict detection, and clear degraded-mode UX. Interviewers want consistency boundaries—not "we cache API responses."

| Component | Role | |-----------|------| | Local store | IndexedDB/SQLite; durable across restarts | | Mutation queue | Ordered ops with client-generated IDs | | Optimistic UI | Apply locally; roll back or mark conflict on failure | | Sync engine | Backoff, batching, background sync (SW), connectivity listeners | | Conflict rules | Last-write-wins vs CRDT vs server merge vs user resolution | | Auth & permissions | Offline reads within cached scope; writes re-validated server-side |

					Offline edit → enqueue { opId, entityVersion, payload } → UI shows pending →
online → POST /sync → 409 CONFLICT → surface merge UI or auto-rule
				

Consistency models: strong on server; client may be eventually consistent. Document what users see when two devices edit the same record offline.

PWA angles: service worker caching strategies differ from data sync—do not confuse static asset cache with authoritative business data.

On interviews: collaborative todo list offline on two devices. Choose identity for ops, conflict strategy, what happens to deletes, and how you test flaky networks.

Common pitfalls: optimistic UI without rollback; silent data loss on conflict; unbounded queue growth; syncing secrets to shared devices; assuming Background Sync API everywhere.

The trade-off is user-perceived immediacy versus complexity of merge logic and support burden for conflict resolution.

Checklist:

• Client op IDs and server versioning or vector clocks.
• Visible sync status and retry affordances.
• Automated tests with simulated offline/online flaps.
• Server remains authority for auth and invariants.