Tervezz offline szinkronizációt egy tanulóalkalmazáshoz: hogyan oldod fel a konfliktusokat?

Question

IT Interview Practice · Accepted Answer

Kezeld az alkalmazást **offline-first** módon: minden eszköz egy helyi **replika**. A tanulási műveletek egy **helyi adatbázisba** és egy csak-hozzáfűző **op logba** (outbox) íródnak; újracsatlakozáskor az eszköz **feltolja az opjait** és **lehúzza a szerver változásait** az utolsó szinkron óta. A konfliktusokat **nem** egyetlen globális szabály oldja fel, hanem **minden adatmező szemantikája**.

**Gondolati modell:** képzeld el **git**-ként — minden eszköz helyileg "commitol" offline, a szinkron pedig **merge**, nem felülírás.

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

- **Helyi adatbázis + op log:** minden változás egy **kliens által generált id-vel rendelkező, változtathatatlan op** + verzió, offline sorba állítva. A UI helyileg olvas/ír, így hálózat nélkül is gördülékeny marad.
- **Sync szolgáltatás:** **cursor-based delta** szinkron — told fel az opokat a kliens cursora óta, húzd le a nála újabb változásokat. Minden szinkron csak a **deltát** mozgatja, nem az egész adathalmazt → 5M felhasználó olcsó marad.
- **Konfliktusfeloldó:** mezőnkénti jelentés szerint mergel (lentebb). **A szerver az igazság forrása**; a kliens előbb felold a gördülékenységért, majd a szerver újra alkalmazza **ugyanazt** a determinisztikus merge-t.

## Konfliktusfeloldás (a lényeg)

A telefonórák **megbízhatatlanok**, és két eszköz offline szerkesztheti ugyanazt a rekordot, ezért a **"last write wins" (LWW) csendben adatot veszít**. Szemantika szerint oldd fel:

- **Monoton mezők** (lecke-haladás) → vedd a **max**-ot.
- **Additív számlálók** (teljes tanulási idő) → **add hozzá a deltát** (CRDT-style grow-only számláló).
- **Valódi "legfrissebb állapot"** (görgetési pozíció) → az LWW elfogadható.

```js
// az opnak van id-je -> alkalmazd idempotensen (az újrapróbálkozások nem számolnak duplán). a clientTs NEM megbízható.
function mergeProgress(server, op) {
  return {
    // a progress csak nő -> max: egy késői régi op sosem húzza vissza
    progress: Math.max(server.progress ?? 0, op.progress),
    // a studiedMs additív számláló -> add hozzá a deltát, ne írd felül
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Itt a sima LWW hagyná, hogy egy elavult eszköz, amely későn szinkronizál `progress: 0.3`-mal, **felülírja** a szerver `0.9`-ét → elveszett haladás. A `max` vétele és a `studiedMs` összegzése **sorrend-függetlenné** teszi a szinkront — biztonságos, amikor milliónyi eszköz szinkronizál elcsúszott órákkal.

## Interjú szemszögéből

A kérdező azt firtatja, tudod-e, hogy **a kliensórák nem megbízhatók** (tehát nem tiszta timestamp LWW), **idempotenssé teszed-e a szinkront** (op id-k), és **az adat jelentése szerint mergelsz-e**. **Gyenge** válasz: "használj timestampeket, last write wins." **Erős** válasz: replika + op log + idempotencia + mezőnkénti merge + szerver mint igazság forrása — és az LWW **adatvesztés**-hibájának kifejezett megnevezése.

## Kompromisszumok

Az LWW olcsó, de veszteséges; a szemantikus merge mezőnkénti gondolkodást igényel, de **semmit sem veszít**. Teljes **CRDT/OT**-hez csak akkor nyúlj, ha valóban kollaboratív szerkesztés kell (jegyzetek, dokumentumok) — költséges, ezért ne használd mindenre.

Architektúra

Konfliktusfeloldás (a lényeg)

Interjú szemszögéből

Kompromisszumok

Kapcsolódó kérdések