Q073: Offline-First Sync and Conflict Resolution

What Interviewers Want To Evaluate

This question tests whether you understand offline UX as distributed systems work in the browser. Interviewers want local persistence, write queues, sync status, retries, conflict detection, conflict resolution, idempotency, background sync, and user trust.

For senior roles, the strongest answer avoids pretending offline support is just localStorage plus retry.

Short Interview Answer

Offline-first apps let users continue working when the network is unavailable by storing data locally, queuing writes, and syncing later. The hard parts are conflict detection, ordering, idempotency, retry policy, storage limits, and clear user feedback. The UI must show what is saved locally, what is syncing, what failed, and when the user needs to resolve a conflict.

Detailed Interview Answer

Offline-first is a product promise. If the app says work is saved, users trust it. Breaking that trust is worse than simply saying offline is not supported.

The design starts by classifying data:

read-only cache
draft user input
queued mutation
server-confirmed data
conflicted data
failed data

Local Persistence

IndexedDB is usually a better fit than localStorage for structured offline data because it handles larger data and asynchronous access. Cache Storage can store request/response pairs for assets or API-like responses.

Local data needs versioning and migration strategy. A new app version may need to understand old local records.

Write Queues

Queued writes should be idempotent when possible. If the same write is retried, the server should not create duplicate records. Idempotency keys help.

The queue needs ordering rules. Some operations can sync independently; others depend on previous writes.

Conflict Resolution

Conflicts happen when local and server data both changed. Strategies include last-write-wins, field-level merge, server wins, client wins, manual resolution, or domain-specific rules.

Manual conflict UX should explain what changed, not dump raw JSON on the user.

Common Mistakes

A common mistake is hiding sync status. Users need to know whether work is local, syncing, confirmed, or failed.

Another mistake is retrying mutations forever without backoff, idempotency, or user-visible failure.

Architecture Discussion

Offline-first architecture spans service workers, IndexedDB, sync queues, API contracts, conflict policy, telemetry, and UX language. It cannot be bolted on at the end for complex products.

Performance Discussion

Large local stores can slow startup and increase memory pressure. Sync should be incremental, batched, and observable.

Security and Privacy Considerations

Local offline data may contain sensitive information. Consider encryption, logout cleanup, device sharing, retention, and tenant separation.

Real Production Story

A field-sales app may let users write visit notes offline. If two devices edit the same account, the app needs conflict policy and clear resolution. Silent overwrite can lose business-critical data.

Enterprise Example

In healthcare, offline workflows need audit trails, sync status, conflict handling, and strict privacy controls. Product language must clearly distinguish local draft from server-confirmed record.

Senior Engineer Perspective

A senior engineer should discuss data model, queue model, conflict policy, user trust, and server contracts.

Code or Design Example

The sync queue should make mutation identity explicit. This helps retries, conflict resolution, and support debugging.

type QueuedMutation = {
  idempotencyKey: string;
  entityId: string;
  operation: "create" | "update" | "delete";
  payload: unknown;
  createdAt: string;
  retryCount: number;
};

The browser can persist this queue locally and the server can use idempotencyKey to avoid duplicate writes when the same mutation is retried.

Lead Engineer Perspective

A lead should define offline eligibility, storage limits, sync telemetry, conflict UX, API idempotency, and support runbooks.

Debugging Workflow

For sync bugs, inspect local records, queue state, mutation IDs, server responses, conflict decisions, retry history, and network transitions. Reproduce with airplane mode and multiple devices.

Revision Notes

Offline-first is distributed state. Local persistence, queued writes, idempotency, conflict resolution, and user-visible status are all required.

Key Takeaways

Do not promise offline editing unless the system can protect user work and explain sync state clearly.

Follow-Up Questions

1. What data should work offline?
2. Why is localStorage often insufficient?
3. What is a write queue?
4. What is idempotency?
5. What causes conflicts?
6. What conflict strategies exist?
7. How should sync status be shown?
8. How do service workers help?
9. How do you handle logout?
10. How do you test offline workflows?

How I Would Answer This In A Real Interview

I would say offline-first is a sync and trust problem. Then I would cover IndexedDB, write queues, idempotency keys, retries, conflict policy, visible sync states, and privacy.