Ontwerp offline sync voor een leer-app: hoe los je conflicten op?

Question

IT Interview Practice · Accepted Answer

Behandel de app als **offline-first**: elk device is een lokale **replica**. Studie-acties worden weggeschreven naar een **lokale DB** plus een append-only **op log** (outbox); bij herverbinding **pusht** het device **zijn ops** en **pullt het serverwijzigingen** sinds de laatste sync. Conflicten worden **niet** opgelost met één globale regel, maar door de **semantiek van elk dataveld**.

**Mentaal model:** zie het als **git** — elk device "commit" lokaal terwijl het offline is, en sync is een **merge**, geen overwrite.

## Architectuur

```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)
```

- **Lokale DB + op log:** elke wijziging is een **immutable op met een client-gegenereerde id** + versie, in de wachtrij gezet terwijl je offline bent. De UI leest/schrijft lokaal, zodat alles soepel blijft zonder netwerk.
- **Sync-service:** **cursor-based delta** sync — push ops sinds de client-cursor, pull wijzigingen die nieuwer zijn. Elke sync verplaatst alleen de **delta**, niet de hele dataset → 5M gebruikers blijft goedkoop.
- **Conflictresolver:** merget op basis van de betekenis per veld (hieronder). De **server is de source of truth**; de client lost eerst op voor de soepelheid, waarna de server dezelfde deterministische merge **opnieuw toepast**.

## Conflictoplossing (de kern)

Telefoonklokken zijn **onbetrouwbaar** en twee devices kunnen hetzelfde record offline bewerken, dus **"last write wins" (LWW) verliest stilletjes data**. Los op via semantiek:

- **Monotone velden** (lesvoortgang) → neem het **maximum**.
- **Additieve tellers** (totale studietijd) → **tel de delta op** (CRDT-achtige grow-only counter).
- **Echte "laatste staat"** (scrollpositie) → LWW is acceptabel.

```js
// op heeft een id -> pas idempotent toe (retries tellen niet dubbel). clientTs wordt NIET vertrouwd.
function mergeProgress(server, op) {
  return {
    // progress neemt alleen toe -> max: een late oude op sleept het nooit terug
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs is een additieve teller -> tel de delta op, niet overschrijven
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Hier zou pure LWW een verouderd device dat laat synct met `progress: 0.3` de `0.9` van de server laten **overschrijven** → verloren voortgang. Het nemen van `max` en het optellen van `studiedMs` maakt sync **volgorde-onafhankelijk** — veilig wanneer miljoenen devices synchroniseren met scheve klokken.

## Interview-lens

De interviewer peilt of je weet dat **client-klokken niet te vertrouwen zijn** (dus geen pure timestamp-LWW), of je **sync idempotent** maakt (op-ids), en of je **merget op basis van databetekenis**. Een **zwak** antwoord: "gebruik timestamps, last write wins." Een **sterk** antwoord: replica + op log + idempotency + merge per veld + server als source of truth — en expliciet de **dataverlies**-faalmodus van LWW benoemen.

## Trade-offs

LWW is goedkoop maar verliesbaar; semantische merge vereist denkwerk per veld maar **verliest niets**. Grijp pas naar volledige **CRDT/OT** wanneer je echte collaboratieve bewerking nodig hebt (notities, documenten) — het is kostbaar, dus gebruik het niet voor alles.

Architectuur

Conflictoplossing (de kern)

Interview-lens

Trade-offs

Gerelateerde vragen