Design offline sync for a learning app: how do you resolve conflicts?

Question

IT Interview Practice · Accepted Answer

Treat the app as **offline-first**: every device is a local **replica**. Study actions are written to a **local DB** plus an append-only **op log** (outbox); on reconnect the device **pushes its ops** and **pulls server changes** since its last sync. Conflicts are resolved **not** by one global rule but by the **semantics of each data field**.

**Mental model:** think of it like **git** — each device "commits" locally while offline, and sync is a **merge**, not an overwrite.

## Architecture

```text
Device (offline)                        Server = source of truth
┌──────────────────┐   on reconnect     ┌───────────────────────────┐
│ Local DB (SQLite)│  push ops (delta)  │ Sync API  /sync           │
│ + Op log (outbox)│ ─────────────────▶ │  • idempotent by op.id    │
│ cursor = lastSeen│ ◀───────────────── │  • merge by semantics     │
└──────────────────┘  pull changes>cursor└───────────────────────────┘
                                         Progress DB (Postgres)
```

- **Local DB + op log:** each change is an **immutable op with a client-generated id** + version, queued while offline. The UI reads/writes locally so it stays smooth with no network.
- **Sync service:** **cursor-based delta** sync — push ops since the client cursor, pull changes newer than it. Each sync moves only the **delta**, not the whole dataset → 5M users stays cheap.
- **Conflict resolver:** merges by per-field meaning (below). The **server is the source of truth**; the client resolves first for smoothness, then the server re-applies the **same** deterministic merge.

## Conflict resolution (the core)

Phone clocks are **unreliable** and two devices can edit the same record offline, so **"last write wins" (LWW) silently loses data**. Resolve by semantics:

- **Monotonic fields** (lesson progress) → take the **max**.
- **Additive counters** (total study time) → **add the delta** (CRDT-style grow-only counter).
- **True "latest state"** (scroll position) → LWW is acceptable.

```js
// op has an id -> apply idempotently (retries don't double-count). clientTs is NOT trusted.
function mergeProgress(server, op) {
  return {
    // progress only increases -> max: a late old op never drags it backward
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs is an additive counter -> add the delta, don't overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Here, plain LWW would let a stale device syncing late with `progress: 0.3` **overwrite** the server's `0.9` → lost progress. Taking `max` and summing `studiedMs` makes sync **order-independent** — safe when millions of devices sync with skewed clocks.

## Interview lens

The interviewer is probing whether you know **client clocks can't be trusted** (so not pure timestamp LWW), whether you make **sync idempotent** (op ids), and whether you **merge by data meaning**. A **weak** answer: "use timestamps, last write wins." A **strong** answer: replica + op log + idempotency + per-field merge + server as source of truth — and naming LWW's **data-loss** failure explicitly.

## Trade-offs

LWW is cheap but lossy; semantic merge needs per-field thought but **loses nothing**. Reach for full **CRDT/OT** only when you need true collaborative editing (notes, documents) — it is costly, so don't use it for everything.

Architecture

Conflict resolution (the core)

Interview lens

Trade-offs

Related questions