Reka bentuk offline sync untuk aplikasi pembelajaran: bagaimana anda menyelesaikan konflik?

Question

IT Interview Practice · Accepted Answer

Anggap aplikasi sebagai **offline-first**: setiap peranti ialah satu **replica** tempatan. Tindakan belajar ditulis ke **local DB** serta satu **op log** append-only (outbox); apabila bersambung semula peranti akan **push ops-nya** dan **pull perubahan pelayan** sejak sync terakhirnya. Konflik diselesaikan **bukan** dengan satu peraturan global tetapi mengikut **semantik setiap medan data**.

**Model mental:** fikirkannya seperti **git** — setiap peranti "commit" secara tempatan semasa offline, dan sync ialah satu **merge**, bukan overwrite.

## Seni bina

```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:** setiap perubahan ialah satu **op tak boleh ubah dengan id yang dijana klien** + versi, dibariskan semasa offline. UI membaca/menulis secara tempatan supaya ia kekal lancar tanpa rangkaian.
- **Sync service:** sync **delta berasaskan cursor** — push ops sejak cursor klien, pull perubahan yang lebih baru daripadanya. Setiap sync hanya menggerakkan **delta**, bukan keseluruhan dataset → 5J pengguna kekal murah.
- **Conflict resolver:** merge mengikut makna setiap medan (di bawah). **Pelayan ialah source of truth**; klien menyelesaikan dahulu untuk kelancaran, kemudian pelayan menggunakan semula merge deterministik yang **sama**.

## Penyelesaian konflik (terasnya)

Jam telefon **tidak boleh dipercayai** dan dua peranti boleh mengedit rekod yang sama semasa offline, jadi **"last write wins" (LWW) senyap-senyap kehilangan data**. Selesaikan mengikut semantik:

- **Medan monotonik** (kemajuan pelajaran) → ambil **max**.
- **Kaunter tambahan** (jumlah masa belajar) → **tambah delta** (kaunter grow-only gaya CRDT).
- **"Keadaan terkini" sebenar** (kedudukan scroll) → LWW boleh diterima.

```js
// op ada id -> guna secara idempoten (retry tidak double-count). clientTs TIDAK dipercayai.
function mergeProgress(server, op) {
  return {
    // progress hanya meningkat -> max: op lama yang lewat tidak menariknya ke belakang
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs ialah kaunter tambahan -> tambah delta, jangan overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Di sini, LWW biasa akan membenarkan peranti basi yang sync lewat dengan `progress: 0.3` **overwrite** `0.9` pelayan → kemajuan hilang. Mengambil `max` dan menjumlahkan `studiedMs` menjadikan sync **tidak bergantung pada susunan** — selamat apabila berjuta peranti sync dengan jam yang tersasar.

## Sudut pandang temu duga

Penemu duga sedang menguji sama ada anda tahu **jam klien tidak boleh dipercayai** (jadi bukan LWW timestamp tulen), sama ada anda menjadikan **sync idempoten** (op ids), dan sama ada anda **merge mengikut makna data**. Jawapan **lemah**: "guna timestamp, last write wins." Jawapan **kuat**: replica + op log + idempotency + merge setiap medan + pelayan sebagai source of truth — dan menamakan secara jelas kegagalan **kehilangan data** LWW.

## Trade-off

LWW murah tetapi lossy; semantic merge memerlukan pertimbangan setiap medan tetapi **tidak kehilangan apa-apa**. Guna **CRDT/OT** penuh hanya apabila anda memerlukan penyuntingan kolaboratif sebenar (nota, dokumen) — ia mahal, jadi jangan gunakannya untuk segala-galanya.

Seni bina

Penyelesaian konflik (terasnya)

Sudut pandang temu duga

Trade-off

Soalan berkaitan