Projekto sinkronizimin offline për një aplikacion mësimor: si i zgjidh konfliktet?

Question

IT Interview Practice · Accepted Answer

Trajtoje aplikacionin si **offline-first**: çdo pajisje është një **replica** lokale. Veprimet e studimit shkruhen në një **DB lokale** plus një **op log** vetëm-shtues (outbox); në rilidhje pajisja **shtyn op-et e saj** dhe **tërheq ndryshimet e serverit** që nga sinkronizimi i fundit. Konfliktet zgjidhen **jo** nga një rregull i vetëm global, por nga **semantika e secilës fushë të dhënash**.

**Modeli mendor:** mendoje si **git** — çdo pajisje bën "commit" lokalisht ndërsa është offline, dhe sinkronizimi është një **merge**, jo një mbishkrim.

## Arkitektura

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

- **DB lokale + op log:** çdo ndryshim është një **op i pandryshueshëm me një id të gjeneruar nga klienti** + version, i vendosur në radhë ndërsa është offline. UI-ja lexon/shkruan lokalisht kështu që mbetet e rrjedhshme pa rrjet.
- **Shërbimi i sinkronizimit:** sinkronizim **delta i bazuar në cursor** — shtyn op-et që nga cursor-i i klientit, tërheq ndryshimet më të reja se ai. Çdo sinkronizim lëviz vetëm **delta-n**, jo të gjithë datasetin → 5M përdorues mbetet i lirë.
- **Zgjidhësi i konflikteve:** bën merge sipas kuptimit të secilës fushë (më poshtë). **Serveri është source of truth**; klienti zgjidh i pari për rrjedhshmëri, pastaj serveri ri-aplikon **të njëjtin** merge determinist.

## Zgjidhja e konflikteve (thelbi)

Orët e telefonave janë **të pabesueshme** dhe dy pajisje mund të editojnë të njëjtin record offline, kështu që **"last write wins" (LWW) humbet të dhëna në heshtje**. Zgjidhi sipas semantikës:

- **Fusha monotonike** (progresi i mësimit) → merr **max**.
- **Numërues aditivë** (koha totale e studimit) → **shto delta-n** (numërues grow-only në stil CRDT).
- **"Gjendja e vërtetë më e fundit"** (pozicioni i scroll-it) → LWW është i pranueshëm.

```js
// op ka një id -> aplikoje në mënyrë idempotente (riprovat nuk numërojnë dyfish). clientTs NUK besohet.
function mergeProgress(server, op) {
  return {
    // progress vetëm rritet -> max: një op i vjetër me vonesë nuk e tërheq kurrë prapa
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs është numërues aditiv -> shto delta-n, mos mbishkruaj
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Këtu, LWW e thjeshtë do të lejonte një pajisje të vjetëruar që sinkronizohet vonë me `progress: 0.3` të **mbishkruante** `0.9` e serverit → progres i humbur. Marrja e `max` dhe mbledhja e `studiedMs` e bën sinkronizimin **të pavarur nga rendi** — i sigurt kur miliona pajisje sinkronizohen me orë të shtrembëruara.

## Këndvështrimi i intervistës

Intervistuesi po heton nëse e di që **orët e klientit nuk mund të besohen** (pra jo LWW i pastër me timestamp), nëse e bën **sinkronizimin idempotent** (op ids), dhe nëse **bën merge sipas kuptimit të të dhënave**. Një përgjigje **e dobët**: "përdor timestamps, last write wins." Një përgjigje **e fortë**: replica + op log + idempotency + merge për-fushë + serveri si source of truth — dhe emërtimi eksplicit i dështimit me **humbje të dhënash** të LWW.

## Kompromiset

LWW është i lirë por humbës; merge semantik kërkon mendim për-fushë por **nuk humbet asgjë**. Përdor **CRDT/OT** të plotë vetëm kur ke nevojë për editim vërtet bashkëpunues (shënime, dokumente) — është i kushtueshëm, ndaj mos e përdor për gjithçka.

Arkitektura

Zgjidhja e konflikteve (thelbi)

Këndvështrimi i intervistës

Kompromiset

Pyetje të ngjashme