Zasnujte offline sync za učno aplikacijo: kako razrešite konflikte?

Question

IT Interview Practice · Accepted Answer

Aplikacijo obravnavajte kot **offline-first**: vsaka naprava je lokalna **replika**. Učna dejanja se zapišejo v **lokalno bazo (DB)** plus append-only **op log** (outbox); ob ponovni povezavi naprava **potisne svoje ope (push)** in **povleče strežniške spremembe (pull)** od svoje zadnje sinhronizacije. Konflikti se ne razrešujejo z enim globalnim pravilom, temveč po **semantiki posameznega podatkovnega polja**.

**Miselni model:** predstavljajte si to kot **git** — vsaka naprava lokalno "commita", medtem ko je offline, sinhronizacija pa je **merge**, ne prepis.

## 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 DB + op log:** vsaka sprememba je **nespremenljiv op z id-jem, ki ga generira odjemalec (client)** + verzija, uvrščen v čakalno vrsto med offline načinom. UI bere/piše lokalno, zato ostane gladek brez omrežja.
- **Sync storitev:** **cursor-based delta** sinhronizacija — potisne ope od odjemalčevega cursorja, povleče spremembe novejše od njega. Vsaka sinhronizacija premakne le **delto**, ne celotnega nabora podatkov → 5M uporabnikov ostane poceni.
- **Razreševalnik konfliktov:** merga po pomenu posameznega polja (spodaj). **Strežnik je source of truth**; odjemalec razreši najprej za gladkost, nato strežnik ponovno uporabi **isti** deterministični merge.

## Razreševanje konfliktov (jedro)

Ure telefonov so **nezanesljive** in dve napravi lahko urejata isti zapis offline, zato **"last write wins" (LWW) tiho izgublja podatke**. Razrešite po semantiki:

- **Monotona polja** (napredek lekcije) → vzemi **max**.
- **Aditivni števci** (skupni čas učenja) → **prištej delto** (grow-only counter v slogu CRDT).
- **Pravo "najnovejše stanje"** (pozicija drsenja) → LWW je sprejemljiv.

```js
// op ima id -> uporabi idempotentno (ponovni poskusi ne štejejo dvojno). clientTs NI zaupanja vreden.
function mergeProgress(server, op) {
  return {
    // progress se le povečuje -> max: pozen star op ga nikoli ne povleče nazaj
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs je aditivni števec -> prištej delto, ne prepiši
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Tukaj bi navadni LWW pustil, da zastarela naprava, ki se sinhronizira pozno z `progress: 0.3`, **prepiše** strežnikov `0.9` → izgubljen napredek. Vzemanje `max` in seštevanje `studiedMs` naredita sinhronizacijo **neodvisno od vrstnega reda** — varno, ko se milijoni naprav sinhronizirajo z zamaknjenimi urami.

## Vidik intervjuja

Izpraševalec preverja, ali veste, da **uram odjemalca ni mogoče zaupati** (torej ne čisti timestamp LWW), ali naredite **sinhronizacijo idempotentno** (op id-ji) in ali **mergate po pomenu podatkov**. **Šibek** odgovor: "uporabi timestampe, last write wins." **Močan** odgovor: replika + op log + idempotentnost + merge po posameznem polju + strežnik kot source of truth — in eksplicitno poimenovanje LWW-jevega **izgubljanja podatkov**.

## Kompromisi

LWW je poceni, a izgubljiv; semantični merge zahteva razmislek o posameznem polju, a **ničesar ne izgubi**. Poseite po polnem **CRDT/OT** le, ko potrebujete pravo sodelovalno urejanje (zapiski, dokumenti) — je drago, zato ga ne uporabljajte za vse.

Arhitektura

Razreševanje konfliktov (jedro)

Vidik intervjuja

Kompromisi

Povezana vprašanja