Suunnittele offline-synkronointi oppimissovellukselle: miten ratkaiset konfliktit?

Question

IT Interview Practice · Accepted Answer

Käsittele sovellusta **offline-first**-periaatteella: jokainen laite on paikallinen **replica**. Opiskelutoiminnot kirjoitetaan **paikalliseen DB:hen** sekä append-only **op-lokiin** (outbox); yhteyden palautuessa laite **työntää op:nsa (push)** ja **hakee palvelimen muutokset (pull)** viimeisimmästä synkronoinnista lähtien. Konfliktit ratkaistaan **ei** yhdellä globaalilla säännöllä vaan **kunkin datakentän semantiikan** mukaan.

**Ajatusmalli:** ajattele sitä kuin **git** — jokainen laite tekee offline-tilassa paikallisen "commitin", ja synkronointi on **merge**, ei ylikirjoitus.

## Arkkitehtuuri

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

- **Paikallinen DB + op-loki:** jokainen muutos on **muuttumaton op, jolla on clientin generoima id** + versio, jonotettuna offline-tilassa. UI lukee/kirjoittaa paikallisesti, joten se pysyy sulavana ilman verkkoa.
- **Sync-palvelu:** **kursoripohjainen delta**-synkronointi — työnnä op:t clientin kursorista lähtien, hae sitä uudemmat muutokset. Jokainen synkronointi siirtää vain **deltan**, ei koko datasettiä → 5M käyttäjää pysyy edullisena.
- **Konfliktinratkaisija:** merge kenttäkohtaisen merkityksen mukaan (alla). **Palvelin on source of truth**; client ratkaisee ensin sulavuuden vuoksi, sitten palvelin soveltaa **saman** deterministisen mergen uudelleen.

## Konfliktinratkaisu (ydin)

Puhelimen kellot ovat **epäluotettavia** ja kaksi laitetta voi muokata samaa tietuetta offline-tilassa, joten **"last write wins" (LWW) hukkaa dataa hiljaisesti**. Ratkaise semantiikan mukaan:

- **Monotoniset kentät** (lesson progress) → ota **max**.
- **Additiiviset laskurit** (kokonaisopiskeluaika) → **lisää delta** (CRDT-tyylinen grow-only-laskuri).
- **Aito "viimeisin tila"** (scroll position) → LWW on hyväksyttävä.

```js
// op:lla on id -> sovella idempotentisti (retryt eivät laske kahdesti). clientTs:hen EI luoteta.
function mergeProgress(server, op) {
  return {
    // progress vain kasvaa -> max: myöhäinen vanha op ei koskaan vedä sitä taaksepäin
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs on additiivinen laskuri -> lisää delta, älä ylikirjoita
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Tässä pelkkä LWW antaisi myöhään synkronoituvan vanhentuneen laitteen arvolla `progress: 0.3` **ylikirjoittaa** palvelimen arvon `0.9` → menetetty edistyminen. `max`:n ottaminen ja `studiedMs`:n summaaminen tekee synkronoinnista **järjestyksestä riippumattoman** — turvallista, kun miljoonat laitteet synkronoivat vinoutuneilla kelloilla.

## Haastattelunäkökulma

Haastattelija tunnustelee, tiedätkö että **clientin kelloihin ei voi luottaa** (siis ei puhdasta timestamp-LWW:tä), teetkö **synkronoinnista idempotentin** (op-idt), ja **mergaatko datan merkityksen mukaan**. **Heikko** vastaus: "käytä timestampeja, last write wins." **Vahva** vastaus: replica + op-loki + idempotenssi + kenttäkohtainen merge + palvelin source of truthina — ja LWW:n **datan menetys** -riskin nimeäminen eksplisiittisesti.

## Kompromissit

LWW on halpa mutta häviöllinen; semanttinen merge vaatii kenttäkohtaista ajattelua mutta **ei hukkaa mitään**. Turvaudu täyteen **CRDT/OT**:hen vain kun tarvitset aitoa yhteismuokkausta (muistiinpanot, dokumentit) — se on kallista, joten älä käytä sitä kaikkeen.

Arkkitehtuuri

Konfliktinratkaisu (ydin)

Haastattelunäkökulma

Kompromissit

Aiheeseen liittyvät kysymykset