Rancangen offline sync kanggo aplikasi sinau: kepiye carane ngrampungake konflik?

Question

IT Interview Practice · Accepted Answer

Anggep aplikasi iki minangka **offline-first**: saben piranti yaiku **replica** lokal. Tumindak sinau ditulis menyang **local DB** plus **op log** append-only (outbox); nalika nyambung maneh piranti **push ops-e** lan **narik owah-owahan server** wiwit sync pungkasan. Konflik dirampungake **ora** nganggo siji aturan global nanging nganggo **semantik saben field data**.

**Model mental:** bayangna kaya **git** — saben piranti "commit" lokal nalika offline, lan sync iku **merge**, dudu overwrite.

## Arsitektur

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

- **Local DB + op log:** saben owah-owahan yaiku **op immutable kanthi id sing digawe client** + versi, diantri nalika offline. UI maca/nulis lokal supaya tetep lancar tanpa jaringan.
- **Sync service:** sync **delta basis-cursor** — push ops wiwit cursor client, narik owah-owahan sing luwih anyar tinimbang iku. Saben sync mindhah mung **delta**, dudu kabeh dataset → 5M pangguna tetep murah.
- **Conflict resolver:** nggabung miturut makna saben-field (ing ngisor). **Server iku source of truth**; client ngrampungake dhisik supaya lancar, banjur server nerapake maneh merge deterministik sing **padha**.

## Ngrampungake konflik (intine)

Jam telpon **ora bisa dipercaya** lan rong piranti bisa ngowahi record sing padha nalika offline, mula **"last write wins" (LWW) ilang data tanpa ana sing weruh**. Rampungna nganggo semantik:

- **Field monotonik** (progress pelajaran) → jupuk **max**.
- **Counter aditif** (total wektu sinau) → **tambahi delta-ne** (grow-only counter gaya CRDT).
- **"Kahanan paling anyar" tenan** (posisi scroll) → LWW bisa ditampa.

```js
// op nduwe id -> terapke kanthi idempoten (retry ora ngetung pindho). clientTs ORA dipercaya.
function mergeProgress(server, op) {
  return {
    // progress mung mundhak -> max: op lawas sing telat ora tau narik mundur
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs iku counter aditif -> tambahi delta, aja overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Ing kene, LWW biasa bakal ngidini piranti kadhaluwarsa sing sync telat kanthi `progress: 0.3` **overwrite** `0.9` ing server → progress ilang. Njupuk `max` lan njumlah `studiedMs` ndadekake sync **ora gumantung urutan** — aman nalika mayuta-yuta piranti sync kanthi jam sing miring.

## Sudut pandang wawancara

Pewawancara nyelidiki apa kowe ngerti **jam client ora bisa dipercaya** (mula dudu LWW timestamp murni), apa kowe ndadekake **sync idempoten** (op id), lan apa kowe **nggabung miturut makna data**. Jawaban **lemah**: "nganggo timestamp, last write wins." Jawaban **kuwat**: replica + op log + idempotensi + merge saben-field + server minangka source of truth — lan nyebut kegagalan **ilang-data** LWW kanthi cetha.

## Trade-off

LWW murah nanging ilang data; merge semantik butuh pikiran saben-field nanging **ora ilang apa-apa**. Nggunakake **CRDT/OT** kebak mung yen kowe butuh editing kolaboratif tenan (cathetan, dokumen) — larang, mula aja dienggo kanggo kabeh.

Arsitektur

Ngrampungake konflik (intine)

Sudut pandang wawancara

Trade-off

Pitakon sing gegandhengan