Designa offline-synk för en inlärningsapp: hur löser du konflikter?

Question

IT Interview Practice · Accepted Answer

Behandla appen som **offline-first**: varje enhet är en lokal **replica**. Studiehandlingar skrivs till en **lokal DB** plus en append-only **op log** (outbox); vid återanslutning **pushar enheten sina ops** och **hämtar serverändringar** sedan sin senaste synk. Konflikter löses **inte** genom en global regel utan genom **semantiken hos varje datafält**.

**Mental modell:** tänk på det som **git** — varje enhet "commit:ar" lokalt medan den är offline, och synk är en **merge**, inte en överskrivning.

## 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:** varje ändring är en **immutabel op med ett klientgenererat id** + version, köad medan den är offline. UI:t läser/skriver lokalt så att det förblir smidigt utan nätverk.
- **Sync-tjänst:** **cursor-baserad delta**-synk — pusha ops sedan klientens cursor, hämta ändringar nyare än den. Varje synk flyttar bara **deltat**, inte hela datasetet → 5M användare förblir billigt.
- **Konfliktlösare:** merger per fältbetydelse (nedan). **Servern är source of truth**; klienten löser först för smidighet, sedan återapplicerar servern **samma** deterministiska merge.

## Konfliktlösning (kärnan)

Telefonklockor är **opålitliga** och två enheter kan redigera samma post offline, så **"last write wins" (LWW) tappar tyst data**. Lös per semantik:

- **Monotona fält** (lektionsframsteg) → ta **max**.
- **Additiva räknare** (total studietid) → **addera deltat** (CRDT-liknande grow-only counter).
- **Äkta "senaste tillstånd"** (scroll-position) → LWW är acceptabelt.

```js
// op har ett id -> applicera idempotent (retries dubbelräknar inte). clientTs litas INTE på.
function mergeProgress(server, op) {
  return {
    // progress ökar bara -> max: en sen gammal op drar den aldrig bakåt
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs är en additiv räknare -> addera deltat, skriv inte över
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Här skulle vanlig LWW låta en föråldrad enhet som synkar sent med `progress: 0.3` **skriva över** serverns `0.9` → förlorat framsteg. Att ta `max` och summera `studiedMs` gör synken **ordningsoberoende** — säkert när miljontals enheter synkar med skeva klockor.

## Intervjuperspektiv

Intervjuaren undersöker om du vet att **klientklockor inte kan litas på** (alltså inte ren timestamp-LWW), om du gör **synk idempotent** (op-ids), och om du **merger per databetydelse**. Ett **svagt** svar: "använd timestamps, last write wins." Ett **starkt** svar: replica + op log + idempotens + per-fält-merge + server som source of truth — och att uttryckligen namnge LWW:s **dataförlust**-fel.

## Avvägningar

LWW är billigt men förlustbenäget; semantisk merge kräver eftertanke per fält men **tappar ingenting**. Ta till fullständig **CRDT/OT** endast när du behöver äkta kollaborativ redigering (anteckningar, dokument) — det är kostsamt, så använd det inte till allt.

Arkitektur

Konfliktlösning (kärnan)

Intervjuperspektiv

Avvägningar

Relaterade frågor