Rancang sinkronisasi offline untuk aplikasi pembelajaran: bagaimana Anda menyelesaikan konflik?

Question

IT Interview Practice · Accepted Answer

Perlakukan aplikasi sebagai **offline-first**: setiap perangkat adalah **replica** lokal. Aksi belajar ditulis ke **DB lokal** plus **op log** append-only (outbox); saat tersambung kembali perangkat **mendorong ops-nya** dan **menarik perubahan server** sejak sinkronisasi terakhir. Konflik diselesaikan **bukan** oleh satu aturan global melainkan oleh **semantik tiap field data**.

**Model mental:** anggap seperti **git** — tiap perangkat "commit" secara lokal saat offline, dan sinkronisasi adalah **merge**, bukan 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)
```

- **DB lokal + op log:** tiap perubahan adalah **op immutable dengan id yang dibuat klien** + version, diantre saat offline. UI membaca/menulis secara lokal sehingga tetap mulus tanpa jaringan.
- **Layanan sync:** sinkronisasi **cursor-based delta** — dorong ops sejak cursor klien, tarik perubahan yang lebih baru darinya. Tiap sinkronisasi hanya memindahkan **delta**, bukan seluruh dataset → 5M pengguna tetap murah.
- **Resolver konflik:** menggabungkan berdasarkan makna per-field (di bawah). **Server adalah source of truth**; klien menyelesaikan lebih dulu demi kemulusan, lalu server menerapkan ulang merge deterministik yang **sama**.

## Resolusi konflik (intinya)

Jam ponsel **tidak dapat diandalkan** dan dua perangkat bisa mengedit record yang sama secara offline, sehingga **"last write wins" (LWW) diam-diam kehilangan data**. Selesaikan berdasarkan semantik:

- **Field monotonik** (progres lesson) → ambil **max**.
- **Counter aditif** (total waktu belajar) → **tambahkan delta** (counter grow-only ala CRDT).
- **"Latest state" sejati** (posisi scroll) → LWW dapat diterima.

```js
// op punya id -> terapkan secara idempoten (retry tidak menghitung dobel). clientTs TIDAK dipercaya.
function mergeProgress(server, op) {
  return {
    // progress hanya naik -> max: op lama yang telat tak pernah menariknya mundur
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs adalah counter aditif -> tambahkan delta-nya, jangan overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Di sini, LWW polos akan membiarkan perangkat basi yang menyinkron terlambat dengan `progress: 0.3` **menimpa** `0.9` milik server → progres hilang. Mengambil `max` dan menjumlahkan `studiedMs` membuat sinkronisasi **tidak bergantung urutan** — aman saat jutaan perangkat menyinkron dengan jam yang melenceng.

## Sudut pandang wawancara

Pewawancara menyelidiki apakah Anda tahu **jam klien tak bisa dipercaya** (jadi bukan timestamp LWW murni), apakah Anda membuat **sync idempoten** (op id), dan apakah Anda **merge berdasarkan makna data**. Jawaban **lemah**: "pakai timestamp, last write wins." Jawaban **kuat**: replica + op log + idempotensi + merge per-field + server sebagai source of truth — dan menyebut secara eksplisit kegagalan **data-loss** LWW.

## Trade-off

LWW murah tapi lossy; semantic merge butuh pemikiran per-field tapi **tak kehilangan apa pun**. Gunakan **CRDT/OT** penuh hanya saat Anda benar-benar butuh collaborative editing (catatan, dokumen) — itu mahal, jadi jangan pakai untuk semuanya.

Arsitektur

Resolusi konflik (intinya)

Sudut pandang wawancara

Trade-off

Pertanyaan terkait