Dizajnirajte offline sinkronizaciju za aplikaciju za učenje: kako razrješavate konflikte?

Question

IT Interview Practice · Accepted Answer

Aplikaciju tretiraj kao **offline-first**: svaki uređaj je lokalna **replika**. Radnje učenja upisuju se u **lokalnu bazu** te u append-only **op log** (outbox); pri ponovnom spajanju uređaj **gura svoje ops** i **povlači promjene sa servera** od zadnje sinkronizacije. Konflikti se razrješavaju **ne** jednim globalnim pravilom nego **semantikom svakog podatkovnog polja**.

**Mentalni model:** zamisli to kao **git** — svaki uređaj lokalno "commita" dok je offline, a sinkronizacija je **merge**, ne prepisivanje.

## Arhitektura

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

- **Lokalna baza + op log:** svaka promjena je **nepromjenjivi op s id-jem koji generira klijent** + verzija, stavljen u red dok je offline. UI čita/piše lokalno pa ostaje gladak bez mreže.
- **Sync servis:** **cursor-based delta** sinkronizacija — gurni ops od klijentskog cursora, povuci promjene novije od njega. Svaka sinkronizacija prenosi samo **deltu**, ne cijeli skup podataka → 5M korisnika ostaje jeftino.
- **Razrješivač konflikata:** spaja prema značenju po polju (niže). **Server je izvor istine**; klijent prvo razrješava radi glatkoće, a zatim server ponovno primjenjuje **isti** deterministički merge.

## Razrješavanje konflikata (srž)

Satovi na telefonima su **nepouzdani** i dva uređaja mogu offline urediti isti zapis, pa **"last write wins" (LWW) tiho gubi podatke**. Razrješavaj prema semantici:

- **Monotona polja** (napredak lekcije) → uzmi **max**.
- **Aditivni brojači** (ukupno vrijeme učenja) → **dodaj deltu** (CRDT-style grow-only brojač).
- **Pravo "najnovije stanje"** (pozicija skrola) → LWW je prihvatljiv.

```js
// op ima id -> primijeni idempotentno (ponovni pokušaji ne broje dvostruko). clientTs se NE vjeruje.
function mergeProgress(server, op) {
  return {
    // progress se samo povećava -> max: kasni stari op nikad ga ne povuče unatrag
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs je aditivni brojač -> dodaj deltu, ne prepisuj
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Ovdje bi obični LWW dopustio da zastarjeli uređaj koji kasno sinkronizira s `progress: 0.3` **prepiše** serverovih `0.9` → izgubljen napredak. Uzimanje `max` i zbrajanje `studiedMs` čini sinkronizaciju **neovisnom o redoslijedu** — sigurno kad milijuni uređaja sinkroniziraju s iskrivljenim satovima.

## Kroz oči intervjua

Ispitivač provjerava znaš li da se **klijentskim satovima ne može vjerovati** (dakle ne čisti timestamp LWW), činiš li **sinkronizaciju idempotentnom** (op id-jevi) i **spajaš li prema značenju podataka**. **Slab** odgovor: "koristi timestampove, last write wins." **Jak** odgovor: replika + op log + idempotentnost + merge po polju + server kao izvor istine — i eksplicitno imenovanje LWW-ovog **gubitka podataka**.

## Kompromisi

LWW je jeftin ali gubi podatke; semantički merge traži razmišljanje po polju ali **ništa ne gubi**. Poseži za punim **CRDT/OT** samo kad ti stvarno treba kolaborativno uređivanje (bilješke, dokumenti) — skupo je, pa ga ne koristi za sve.

Arhitektura

Razrješavanje konflikata (srž)

Kroz oči intervjua

Kompromisi

Povezana pitanja