Navrhni offline synchronizaci pro vzdělávací aplikaci: jak řešíš konflikty?

Question

IT Interview Practice · Accepted Answer

Ber aplikaci jako **offline-first**: každé zařízení je lokální **replika**. Studijní akce se zapisují do **lokální DB** plus do append-only **op logu** (outbox); po opětovném připojení zařízení **odešle své operace** a **stáhne změny ze serveru** od své poslední synchronizace. Konflikty se neřeší **jedním** globálním pravidlem, ale **sémantikou každého datového pole**.

**Mentální model:** představ si to jako **git** — každé zařízení lokálně „commituje" v offline režimu a synchronizace je **merge**, ne přepis.

## Architektura

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

- **Lokální DB + op log:** každá změna je **neměnná operace s id vygenerovaným na klientovi** + verze, zařazená do fronty v offline režimu. UI čte/zapisuje lokálně, takže zůstává plynulé i bez sítě.
- **Sync služba:** synchronizace **delta založená na kurzoru** — odešli operace od kurzoru klienta, stáhni změny novější než tento kurzor. Každá synchronizace přenese jen **deltu**, ne celý dataset → 5M uživatelů zůstává levných.
- **Resolver konfliktů:** merguje podle významu jednotlivých polí (níže). **Zdrojem pravdy je server**; klient řeší konflikt první kvůli plynulosti, pak server znovu aplikuje **stejný** deterministický merge.

## Řešení konfliktů (jádro)

Hodiny v telefonu jsou **nespolehlivé** a dvě zařízení mohou editovat stejný záznam offline, takže **„last write wins" (LWW) tiše ztrácí data**. Řeš podle sémantiky:

- **Monotónní pole** (postup lekce) → vezmi **max**.
- **Aditivní čítače** (celkový čas studia) → **přičti deltu** (grow-only čítač ve stylu CRDT).
- **Skutečný „poslední stav"** (pozice scrollu) → LWW je přijatelné.

```js
// op má id -> aplikuj idempotentně (opakování nezapočítá dvakrát). clientTs se NEdůvěřuje.
function mergeProgress(server, op) {
  return {
    // progress jen roste -> max: pozdní stará op ho nikdy netáhne zpět
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs je aditivní čítač -> přičti deltu, nepřepisuj
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Zde by prosté LWW nechalo zastaralé zařízení synchronizující se pozdě s `progress: 0.3` **přepsat** serverových `0.9` → ztracený postup. Vzetí `max` a sečtení `studiedMs` činí synchronizaci **nezávislou na pořadí** — bezpečné, když se miliony zařízení synchronizují s rozházenými hodinami.

## Pohled tazatele

Tazatel zkoumá, zda víš, že **hodinám klienta nelze věřit** (tedy ne čisté timestamp LWW), zda děláš **synchronizaci idempotentní** (op id) a zda **merguješ podle významu dat**. **Slabá** odpověď: „použij timestampy, last write wins." **Silná** odpověď: replika + op log + idempotence + merge po jednotlivých polích + server jako zdroj pravdy — a explicitní pojmenování **ztráty dat** u LWW.

## Kompromisy

LWW je levné, ale ztrátové; sémantický merge vyžaduje promyšlení po jednotlivých polích, ale **nic neztrácí**. Po plné **CRDT/OT** sáhni jen tehdy, když potřebuješ skutečnou kolaborativní editaci (poznámky, dokumenty) — je nákladná, takže ji nepoužívej na všechno.

Architektura

Řešení konfliktů (jádro)

Pohled tazatele

Kompromisy

Související otázky