Suprojektuokite mokymosi programėlės offline sinchronizaciją: kaip sprendžiate konfliktus?

Question

IT Interview Practice · Accepted Answer

Traktuokite programėlę kaip **offline-first**: kiekvienas įrenginys yra lokali **replika**. Mokymosi veiksmai rašomi į **lokalią DB** plius į tik-pridedamą **op log** (outbox); prisijungus iš naujo įrenginys **išsiunčia savo ops** ir **parsisiunčia serverio pakeitimus** nuo paskutinės sinchronizacijos. Konfliktai sprendžiami **ne** viena globalia taisykle, o pagal **kiekvieno duomenų lauko semantiką**.

**Mąstymo modelis:** įsivaizduokite tai kaip **git** — kiekvienas įrenginys „commit'ina" lokaliai būdamas offline, o sinchronizacija yra **merge**, ne overwrite.

## Architektūra

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

- **Lokali DB + op log:** kiekvienas pakeitimas yra **nekintanti op su kliento sugeneruotu id** + versija, sudedama į eilę būnant offline. UI skaito/rašo lokaliai, todėl lieka sklandus be tinklo.
- **Sinchronizacijos servisas:** **cursor pagrindu veikianti delta** sinchronizacija — išsiunčia ops nuo kliento cursor, parsisiunčia pakeitimus, naujesnius už jį. Kiekviena sinchronizacija perkelia tik **delta**, ne visą duomenų rinkinį → 5 mln. naudotojų lieka pigu.
- **Konfliktų sprendėjas:** sulieja pagal kiekvieno lauko prasmę (žemiau). **Serveris yra source of truth**; klientas sprendžia pirmas dėl sklandumo, tada serveris iš naujo pritaiko **tą patį** deterministinį merge.

## Konfliktų sprendimas (esmė)

Telefonų laikrodžiai yra **nepatikimi**, ir du įrenginiai gali redaguoti tą patį įrašą būdami offline, todėl **„last write wins" (LWW) tyliai praranda duomenis**. Spręskite pagal semantiką:

- **Monotoniniai laukai** (pamokos progresas) → imkite **max**.
- **Sumuojantys skaitikliai** (bendras mokymosi laikas) → **pridėkite delta** (CRDT stiliaus grow-only counter).
- **Tikra „naujausia būsena"** (slinkties pozicija) → LWW yra priimtinas.

```js
// op turi id -> taikoma idempotentiškai (pakartojimai neskaičiuoja dvigubai). clientTs NĖRA patikimas.
function mergeProgress(server, op) {
  return {
    // progresas tik didėja -> max: vėlyva sena op niekada jo netempia atgal
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs yra sumuojantis skaitiklis -> pridėk delta, neperrašyk
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Čia paprastas LWW leistų pasenusiam įrenginiui, sinchronizuojančiam vėlai su `progress: 0.3`, **perrašyti** serverio `0.9` → prarastas progresas. Imant `max` ir sumuojant `studiedMs`, sinchronizacija tampa **nepriklausoma nuo eiliškumo** — saugu, kai milijonai įrenginių sinchronizuojasi su iškreiptais laikrodžiais.

## Interviu perspektyva

Interviuotojas tikrina, ar žinote, kad **kliento laikrodžiais negalima pasitikėti** (taigi ne grynas timestamp LWW), ar padarote **sinchronizaciją idempotentišką** (op id) ir ar **suliejate pagal duomenų prasmę**. **Silpnas** atsakymas: „naudok timestamps, last write wins." **Stiprus** atsakymas: replika + op log + idempotencija + kiekvieno lauko merge + serveris kaip source of truth — ir aiškiai įvardinant LWW **duomenų praradimo** gedimą.

## Kompromisai

LWW pigus, bet nuostolingas; semantinis merge reikalauja apgalvojimo kiekvienam laukui, bet **nieko nepraranda**. Griebkitės pilno **CRDT/OT** tik tada, kai reikia tikro bendradarbiaujamojo redagavimo (užrašai, dokumentai) — tai brangu, tad nenaudokite jo visur.

Architektūra

Konfliktų sprendimas (esmė)

Interviu perspektyva

Kompromisai

Susiję klausimai