Thiết kế offline sync cho app học tập: xử lý conflict resolution ra sao?

Question

IT Interview Practice · Accepted Answer

Coi app là **offline-first**: mỗi thiết bị là một **bản sao (replica)** cục bộ. Thao tác học được ghi vào **DB cục bộ** + một **op log** (hàng đợi thay đổi, append-only); khi online lại, thiết bị **đẩy các op** lên và **kéo về thay đổi** kể từ lần đồng bộ cuối. Xung đột **không** xử lý bằng một quy tắc chung, mà **theo ngữ nghĩa của từng trường dữ liệu**.

**Mô hình dễ hình dung:** giống **git** — mỗi thiết bị "commit" cục bộ khi offline, còn sync là một lần **merge**, không phải ghi đè.

## Kiến trúc

```text
Thiết bị (offline)                      Server = source of truth
┌──────────────────┐   online lại       ┌───────────────────────────┐
│ Local DB (SQLite)│  push ops (delta)  │ Sync API  /sync           │
│ + Op log (outbox)│ ─────────────────▶ │  • idempotent theo op.id  │
│ cursor = lastSeen│ ◀───────────────── │  • merge theo ngữ nghĩa   │
└──────────────────┘  pull changes>cursor└───────────────────────────┘
                                         Progress DB (Postgres)
```

- **Local DB + op log:** mỗi thay đổi là một **op bất biến, có id (client sinh)** + version, xếp hàng khi offline. UI đọc/ghi cục bộ nên vẫn mượt khi mất mạng.
- **Sync service:** đồng bộ **delta theo cursor** — đẩy op kể từ cursor của client, kéo về thay đổi mới hơn cursor. Nhờ vậy mỗi lần sync chỉ chuyển **phần thay đổi**, không phải toàn bộ dữ liệu → 5M user vẫn nhẹ.
- **Conflict resolver:** hợp nhất theo ý nghĩa từng trường (mục dưới). **Server là source of truth**, client giải quyết trước cho mượt rồi server tái áp bằng **cùng** hàm merge (deterministic).

## Conflict resolution (trọng tâm)

Đồng hồ điện thoại **không đáng tin** và hai thiết bị có thể sửa cùng bản ghi khi offline, nên **"ghi sau thắng" (LWW) sẽ âm thầm mất dữ liệu**. Giải quyết theo ngữ nghĩa:

- **Trường đơn điệu tăng** (tiến độ bài học) → lấy **max**.
- **Counter cộng dồn** (tổng thời gian học) → **cộng delta** (kiểu CRDT grow-only counter).
- **"Trạng thái cuối" thật sự** (vị trí đang xem) → LWW chấp nhận được.

```js
// op có id -> áp idempotent (retry không cộng đôi). clientTs KHÔNG đáng tin.
function mergeProgress(server, op) {
  return {
    // progress đơn điệu tăng -> max: op cũ tới muộn cũng không kéo lùi tiến độ
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs là counter cộng dồn -> cộng delta, không ghi đè
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Ở đây, LWW thuần sẽ để một máy cũ sync muộn với `progress: 0.3` **đè** lên `0.9` trên server → mất tiến độ. Lấy `max` và cộng dồn `studiedMs` khiến sync **không phụ thuộc thứ tự tới** — an toàn khi hàng triệu thiết bị đồng bộ lệch giờ.

## Góc nhìn phỏng vấn

Người phỏng vấn đang dò: bạn có biết **đồng hồ client không tin được** (nên không phải LWW theo timestamp thuần), có làm **sync idempotent** (op id) và có **hợp nhất theo ý nghĩa dữ liệu** không. Câu trả lời **yếu**: "dùng timestamp, ghi sau thắng". Câu **mạnh**: replica + op log + idempotency + merge theo trường + server là source of truth — và gọi tên đúng **điểm mất dữ liệu của LWW**.

## Đánh đổi

LWW rẻ nhưng lossy; semantic merge cần hiểu từng trường nhưng **không mất dữ liệu**. Chỉ dùng **CRDT/OT** đầy đủ khi cần soạn thảo cộng tác thật (ghi chú, văn bản) — đừng dùng cho mọi thứ vì tốn kém.

Kiến trúc

Conflict resolution (trọng tâm)

Góc nhìn phỏng vấn

Đánh đổi

Câu hỏi liên quan