Design offline-sync til en læringsapp: hvordan løser du konflikter?

Question

IT Interview Practice · Accepted Answer

Behandl appen som **offline-first**: hver enhed er en lokal **replica**. Studiehandlinger skrives til en **lokal DB** plus en append-only **op-log** (outbox); ved genforbindelse **pusher enheden sine ops** og **puller server-ændringer** siden sin sidste sync. Konflikter løses **ikke** af én global regel, men af **semantikken for hvert datafelt**.

**Mental model:** tænk på det som **git** — hver enhed "committer" lokalt mens den er offline, og sync er en **merge**, ikke en overskrivning.

## 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 ændring er en **immutable op med et klient-genereret id** + version, sat i kø mens enheden er offline. UI'et læser/skriver lokalt, så det forbliver flydende uden netværk.
- **Sync-service:** **cursor-baseret delta**-sync — push ops siden klientens cursor, pull ændringer der er nyere end den. Hver sync flytter kun **delta'et**, ikke hele datasættet → 5M brugere forbliver billigt.
- **Konflikt-resolver:** merger efter betydningen af hvert felt (nedenfor). **Serveren er source of truth**; klienten resolver først for flydende brug, derefter genanvender serveren den **samme** deterministiske merge.

## Konfliktløsning (kernen)

Telefon-ure er **upålidelige**, og to enheder kan redigere den samme record offline, så **"last write wins" (LWW) taber stille data**. Løs efter semantik:

- **Monotone felter** (lektionsfremgang) → tag **max**.
- **Additive tællere** (samlet studietid) → **læg delta'et til** (CRDT-agtig grow-only counter).
- **Ægte "seneste tilstand"** (scroll-position) → LWW er acceptabelt.

```js
// op har et id -> anvend idempotent (retries dobbelttæller ikke). clientTs er IKKE betroet.
function mergeProgress(server, op) {
  return {
    // progress stiger kun -> max: en sen gammel op trækker den aldrig baglæns
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs er en additiv tæller -> læg delta til, overskriv ikke
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Her ville almindelig LWW lade en forældet enhed, der syncer sent med `progress: 0.3`, **overskrive** serverens `0.9` → tabt fremgang. At tage `max` og summere `studiedMs` gør sync **rækkefølge-uafhængig** — sikkert når millioner af enheder syncer med skæve ure.

## Interview lens

Intervieweren undersøger om du ved at **klient-ure ikke kan betros** (altså ikke ren timestamp-LWW), om du gør **sync idempotent** (op-ids), og om du **merger efter databetydning**. Et **svagt** svar: "brug timestamps, last write wins." Et **stærkt** svar: replica + op-log + idempotens + per-felt-merge + server som source of truth — og at navngive LWW's **datatab**-fejl eksplicit.

## Trade-offs

LWW er billig men lossy; semantisk merge kræver per-felt tanke men **taber intet**. Grib til fuld **CRDT/OT** kun når du har brug for ægte collaborative editing (noter, dokumenter) — det er dyrt, så brug det ikke til alt.

Arkitektur

Konfliktløsning (kernen)

Interview lens

Trade-offs

Relaterede spørgsmål