Offline-Sync für eine Lern-App entwerfen: Wie löst du Konflikte auf?

Question

IT Interview Practice · Accepted Answer

Behandle die App als **offline-first**: Jedes Gerät ist eine lokale **Replica**. Lernaktionen werden in eine **lokale DB** plus ein append-only **Op-Log** (Outbox) geschrieben; beim Reconnect **pusht das Gerät seine Ops** und **pullt Server-Änderungen** seit dem letzten Sync. Konflikte werden **nicht** durch eine einzige globale Regel gelöst, sondern durch die **Semantik jedes einzelnen Datenfelds**.

**Mentales Modell:** Stell es dir wie **git** vor — jedes Gerät "committet" offline lokal, und Sync ist ein **Merge**, kein Überschreiben.

## Architektur

```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:** Jede Änderung ist eine **unveränderliche Op mit einer client-generierten id** + Version, die offline in die Queue gestellt wird. Die UI liest/schreibt lokal und bleibt so flüssig, ganz ohne Netzwerk.
- **Sync-Service:** **cursor-basierter Delta**-Sync — pushe Ops seit dem Client-Cursor, pulle Änderungen, die neuer sind. Jeder Sync bewegt nur das **Delta**, nicht den gesamten Datenbestand → 5 Mio. Nutzer bleiben günstig.
- **Konflikt-Resolver:** merged nach der Bedeutung jedes Felds (unten). Der **Server ist die source of truth**; der Client löst zuerst für Flüssigkeit auf, dann wendet der Server denselben deterministischen Merge **erneut** an.

## Konfliktauflösung (der Kern)

Handy-Uhren sind **unzuverlässig** und zwei Geräte können denselben Datensatz offline bearbeiten, daher **verliert "last write wins" (LWW) still und heimlich Daten**. Löse nach Semantik auf:

- **Monotone Felder** (Lektionsfortschritt) → nimm das **Maximum**.
- **Additive Zähler** (gesamte Lernzeit) → **addiere das Delta** (CRDT-artiger grow-only Counter).
- **Echter "latest state"** (Scroll-Position) → LWW ist akzeptabel.

```js
// op hat eine id -> idempotent anwenden (Retries zählen nicht doppelt). clientTs wird NICHT vertraut.
function mergeProgress(server, op) {
  return {
    // progress steigt nur -> max: eine späte alte Op zieht ihn nie zurück
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs ist ein additiver Zähler -> addiere das Delta, überschreibe nicht
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Hier würde reines LWW ein veraltetes Gerät, das spät mit `progress: 0.3` synct, die `0.9` des Servers **überschreiben** lassen → verlorener Fortschritt. Das `max` zu nehmen und `studiedMs` zu summieren macht den Sync **reihenfolge-unabhängig** — sicher, wenn Millionen von Geräten mit verzerrten Uhren synchronisieren.

## Interview-Perspektive

Der Interviewer prüft, ob du weißt, dass **Client-Uhren nicht vertrauenswürdig sind** (also kein reines Timestamp-LWW), ob du **Sync idempotent** machst (Op-ids) und ob du **nach Datenbedeutung merged**. Eine **schwache** Antwort: "Timestamps verwenden, last write wins." Eine **starke** Antwort: Replica + Op-Log + Idempotenz + Per-Field-Merge + Server als source of truth — und LWWs **Datenverlust**-Fehler explizit benennen.

## Trade-offs

LWW ist günstig, aber verlustbehaftet; semantischer Merge braucht Überlegung pro Feld, **verliert aber nichts**. Greife nur dann zu vollem **CRDT/OT**, wenn du echtes kollaboratives Editieren brauchst (Notizen, Dokumente) — es ist teuer, also nutze es nicht für alles.

Architektur

Konfliktauflösung (der Kern)

Interview-Perspektive

Trade-offs

Ähnliche Fragen