Proiectează sincronizarea offline pentru o aplicație de învățare: cum rezolvi conflictele?

Question

IT Interview Practice · Accepted Answer

Tratează aplicația ca fiind **offline-first**: fiecare dispozitiv este o **replică** locală. Acțiunile de studiu sunt scrise într-o **bază de date locală** plus un **op log** append-only (outbox); la reconectare dispozitivul **își trimite ops** (push) și **preia modificările de la server** (pull) de la ultima sincronizare. Conflictele sunt rezolvate **nu** printr-o regulă globală unică, ci prin **semantica fiecărui câmp de date**.

**Model mental:** gândește-te ca la **git** — fiecare dispozitiv face „commit” local cât timp este offline, iar sincronizarea este un **merge**, nu o suprascriere.

## Arhitectură

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

- **Baza de date locală + op log:** fiecare modificare este o **op imutabilă cu un id generat de client** + versiune, pusă în coadă cât timp este offline. UI-ul citește/scrie local, așa că rămâne fluid, fără rețea.
- **Serviciul de sync:** sincronizare **delta bazată pe cursor** — trimite ops de la cursorul clientului, preia modificările mai noi decât acesta. Fiecare sincronizare mută doar **delta**, nu întregul set de date → 5M de utilizatori rămâne ieftin.
- **Rezolvatorul de conflicte:** face merge după semnificația fiecărui câmp (mai jos). **Serverul este source of truth**; clientul rezolvă primul pentru fluiditate, apoi serverul reaplică **același** merge determinist.

## Rezolvarea conflictelor (nucleul)

Ceasurile telefoanelor sunt **nesigure** și două dispozitive pot edita offline aceeași înregistrare, așa că **„last write wins” (LWW) pierde date în tăcere**. Rezolvă prin semantică:

- **Câmpuri monotone** (progresul la lecție) → ia **maximul**.
- **Contoare aditive** (timpul total de studiu) → **adună delta** (contor grow-only în stil CRDT).
- **„Cea mai recentă stare” reală** (poziția scroll-ului) → LWW este acceptabil.

```js
// op are un id -> aplică idempotent (reîncercările nu numără dublu). clientTs NU este de încredere.
function mergeProgress(server, op) {
  return {
    // progress doar crește -> max: o op veche întârziată nu-l trage niciodată înapoi
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs este un contor aditiv -> adună delta, nu suprascrie
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Aici, LWW simplu ar lăsa un dispozitiv învechit care sincronizează târziu cu `progress: 0.3` să **suprascrie** valoarea `0.9` a serverului → progres pierdut. Luarea `max` și însumarea `studiedMs` fac sincronizarea **independentă de ordine** — sigură când milioane de dispozitive sincronizează cu ceasuri decalate.

## Perspectiva de interviu

Intervievatorul verifică dacă știi că **ceasurile clientului nu pot fi de încredere** (deci nu LWW pur pe bază de timestamp), dacă faci **sincronizarea idempotentă** (op ids) și dacă faci **merge după semnificația datelor**. Un răspuns **slab**: „folosește timestamps, last write wins.” Un răspuns **puternic**: replică + op log + idempotență + merge per-câmp + serverul ca source of truth — și numirea explicită a eșecului de **pierdere de date** al LWW.

## Compromisuri

LWW este ieftin, dar cu pierderi; merge-ul semantic necesită gândire per-câmp, dar **nu pierde nimic**. Apelează la **CRDT/OT** complet doar când ai nevoie de editare colaborativă reală (notițe, documente) — este costisitor, așa că nu-l folosi pentru orice.

Arhitectură

Rezolvarea conflictelor (nucleul)

Perspectiva de interviu

Compromisuri

Întrebări conexe