Design offline-synk for en læringsapp: hvordan løser du konflikter?

Question

IT Interview Practice · Accepted Answer

Behandle appen som **offline-first**: hver enhet er en lokal **replica**. Studiehandlinger skrives til en **lokal DB** pluss en append-only **op log** (outbox); ved gjentilkobling **pusher enheten sine ops** og **puller server-endringer** siden siste synk. Konflikter løses **ikke** av én global regel, men av **semantikken til hvert datafelt**.

**Mental modell:** tenk på det som **git** — hver enhet «committer» lokalt mens den er offline, og synk er en **merge**, ikke en overskriving.

## Arkitektur

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

- **Lokal DB + op log:** hver endring er en **immutable op med en klient-generert id** + versjon, køet mens den er offline. UI-et leser/skriver lokalt, så det holder seg jevnt uten nettverk.
- **Sync-tjeneste:** **cursor-basert delta**-synk — push ops siden klientens cursor, pull endringer nyere enn den. Hver synk flytter kun **deltaet**, ikke hele datasettet → 5M brukere forblir billig.
- **Konfliktløser:** merger etter per-felt-mening (under). **Serveren er source of truth**; klienten løser først for jevnhet, deretter re-applyer serveren den **samme** deterministiske mergen.

## Konfliktløsning (kjernen)

Telefonklokker er **upålitelige** og to enheter kan redigere samme record offline, så **«last write wins» (LWW) taper data stille**. Løs etter semantikk:

- **Monotone felter** (leksjonsfremdrift) → ta **max**.
- **Additive tellere** (total studietid) → **legg til deltaet** (CRDT-lignende grow-only counter).
- **Ekte «siste tilstand»** (scroll-posisjon) → LWW er akseptabelt.

```js
// op har en id -> apply idempotent (retries dobbelttelles ikke). clientTs er IKKE til å stole på.
function mergeProgress(server, op) {
  return {
    // progress øker bare -> max: en sen gammel op drar den aldri bakover
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs er en additiv teller -> legg til deltaet, ikke overskriv
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Her ville ren LWW latt en utdatert enhet som synker sent med `progress: 0.3` **overskrive** serverens `0.9` → tapt fremdrift. Å ta `max` og summere `studiedMs` gjør synk **ordens-uavhengig** — trygt når millioner av enheter synker med skjeve klokker.

## Intervjuperspektiv

Intervjueren undersøker om du vet at **klientklokker ikke er til å stole på** (altså ikke ren timestamp-LWW), om du gjør **synk idempotent** (op ids), og om du **merger etter datamening**. Et **svakt** svar: «bruk timestamps, last write wins.» Et **sterkt** svar: replica + op log + idempotens + per-felt-merge + server som source of truth — og å navngi LWW-ens **datatap**-feil eksplisitt.

## Avveininger

LWW er billig, men tapt-utsatt; semantisk merge krever per-felt-tenkning, men **taper ingenting**. Grip til full **CRDT/OT** kun når du trenger ekte samarbeidsredigering (notater, dokumenter) — det er kostbart, så ikke bruk det til alt.

Arkitektur

Konfliktløsning (kjernen)

Intervjuperspektiv

Avveininger

Relaterte spørsmål