ออกแบบระบบ offline sync สำหรับแอปเรียนรู้: คุณจะแก้ปัญหา conflict อย่างไร?

Question

IT Interview Practice · Accepted Answer

มองแอปเป็นแบบ **offline-first**: ทุกอุปกรณ์คือ **replica** ในเครื่อง แอ็กชันการเรียนถูกเขียนลง **local DB** พร้อมกับ **op log** แบบ append-only (outbox); เมื่อกลับมาเชื่อมต่อ อุปกรณ์จะ **push ops ของตัวเอง** และ **pull การเปลี่ยนแปลงจากเซิร์ฟเวอร์** นับตั้งแต่การ sync ครั้งล่าสุด conflict ถูกแก้ **ไม่ใช่** ด้วยกฎกลางเพียงข้อเดียว แต่ด้วย **ความหมาย (semantics) ของแต่ละฟิลด์ข้อมูล**

**แบบจำลองความคิด:** คิดเหมือน **git** — แต่ละอุปกรณ์ "commit" ในเครื่องขณะออฟไลน์ และ sync คือการ **merge** ไม่ใช่การเขียนทับ

## สถาปัตยกรรม

```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:** แต่ละการเปลี่ยนแปลงคือ **op ที่ไม่เปลี่ยนแปลง (immutable) พร้อม id ที่สร้างจากฝั่ง client** + version ถูกจัดคิวไว้ขณะออฟไลน์ UI อ่าน/เขียนในเครื่อง จึงลื่นไหลโดยไม่ต้องใช้เครือข่าย
- **Sync service:** sync แบบ **cursor-based delta** — push ops นับตั้งแต่ cursor ของ client แล้ว pull การเปลี่ยนแปลงที่ใหม่กว่านั้น การ sync แต่ละครั้งย้ายเฉพาะ **delta** ไม่ใช่ชุดข้อมูลทั้งหมด → ผู้ใช้ 5M คนก็ยังต้นทุนต่ำ
- **Conflict resolver:** merge ตามความหมายของแต่ละฟิลด์ (ด้านล่าง) **เซิร์ฟเวอร์คือ source of truth**; client แก้ก่อนเพื่อความลื่นไหล จากนั้นเซิร์ฟเวอร์ re-apply การ merge แบบ deterministic **ชุดเดียวกัน**

## การแก้ conflict (แก่นสำคัญ)

นาฬิกาของโทรศัพท์ **เชื่อถือไม่ได้** และสองอุปกรณ์อาจแก้ record เดียวกันขณะออฟไลน์ ดังนั้น **"last write wins" (LWW) จึงทำข้อมูลหายไปเงียบ ๆ** ให้แก้ตามความหมาย:

- **ฟิลด์แบบ monotonic** (ความคืบหน้าบทเรียน) → เอาค่า **max**
- **ตัวนับแบบบวกเพิ่ม** (เวลาเรียนรวม) → **บวก delta** เข้าไป (grow-only counter แบบ CRDT)
- **สถานะ "ล่าสุด" จริง ๆ** (ตำแหน่ง scroll) → LWW ยอมรับได้

```js
// op มี id -> apply แบบ idempotent (retry ไม่นับซ้ำ). clientTs ไม่ถูกเชื่อถือ
function mergeProgress(server, op) {
  return {
    // progress เพิ่มขึ้นได้อย่างเดียว -> max: op เก่าที่มาช้าจะไม่ลากค่าให้ถอยหลัง
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs เป็นตัวนับแบบบวกเพิ่ม -> บวก delta อย่าเขียนทับ
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

ตรงนี้ LWW แบบธรรมดาจะปล่อยให้อุปกรณ์ที่ค้างอยู่แล้ว sync ช้าด้วย `progress: 0.3` มา **เขียนทับ** ค่า `0.9` ของเซิร์ฟเวอร์ → ความคืบหน้าหาย การเอา `max` และบวก `studiedMs` ทำให้ sync **ไม่ขึ้นกับลำดับ (order-independent)** — ปลอดภัยเมื่อมีอุปกรณ์นับล้านเครื่อง sync ด้วยนาฬิกาที่เพี้ยน

## มุมมองของผู้สัมภาษณ์

ผู้สัมภาษณ์กำลังตรวจว่าคุณรู้ว่า **นาฬิกาฝั่ง client เชื่อถือไม่ได้** หรือไม่ (จึงไม่ใช่ timestamp LWW ล้วน ๆ), คุณทำ sync ให้ **idempotent** หรือไม่ (op ids), และคุณ **merge ตามความหมายของข้อมูล** หรือไม่ คำตอบที่ **อ่อน**: "ใช้ timestamp, last write wins" คำตอบที่ **แข็งแรง**: replica + op log + idempotency + merge รายฟิลด์ + เซิร์ฟเวอร์เป็น source of truth — และระบุจุดล้มเหลวแบบ **ข้อมูลหาย (data-loss)** ของ LWW อย่างชัดเจน

## Trade-offs

LWW ราคาถูกแต่ทำข้อมูลหาย; semantic merge ต้องคิดรายฟิลด์แต่ **ไม่สูญเสียอะไรเลย** ให้เอื้อมไปหา **CRDT/OT** เต็มรูปแบบเฉพาะเมื่อคุณต้องการการแก้ไขร่วมกันจริง ๆ (โน้ต, เอกสาร) — มันมีต้นทุนสูง ดังนั้นอย่าใช้กับทุกอย่าง

สถาปัตยกรรม

การแก้ conflict (แก่นสำคัญ)

มุมมองของผู้สัมภาษณ์

Trade-offs

คำถามที่เกี่ยวข้อง