คุณจะออกแบบ multi-region DB เพื่อ HA และ DR อย่างไร?

Question

IT Interview Practice · Accepted Answer

Replicate database ข้าม region และเลือก topology ตามความต้องการ: **active-passive** (ผู้เขียนเดียว, warm standby ที่รับช่วงตอน failover) เพื่อความเรียบง่ายและ strong consistency หรือ **active-active** (ผู้เขียนหลายตัว) เพื่อ write latency ต่ำโดยแลกกับการ resolve conflict — จากนั้นเลือก **sync vs async replication** เพื่อแลกเปลี่ยน durability กับ latency และนิยามเป้า **RPO/RTO** ที่ชัดเจนซึ่งขับเคลื่อน failover

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive** มี primary หนึ่งตัวจัดการการเขียนและ standby ที่อ่านได้อย่างเดียว เมื่อล้มเหลวคุณ **promote** standby มันเรียบง่ายและหลีกเลี่ยง write conflict แต่ capacity ที่ passive นั่งว่างและ failover มีช่องว่าง **Active-active** ให้ทุก region รับการเขียนเพื่อ latency ในพื้นที่และไม่มี failover promotion — แต่สอง region สามารถแก้ row เดียวกันพร้อมกัน ดังนั้นคุณ *ต้อง* resolve conflict (last-write-wins, CRDT หรือ app-level merge) ทีมส่วนใหญ่เริ่มด้วย active-passive active-active มีไว้สำหรับ write latency ระดับ global ที่คุณทำอย่างอื่นไม่ได้จริง ๆ

## Sync vs async replication

นี่คือข้อแลกเปลี่ยน durability/latency หลัก **Synchronous:** primary รอให้ remote replica ack ก่อน commit — **RPO = 0** (ไม่มีข้อมูลสูญหายตอน failover) แต่ทุกการเขียนจ่าย cross-region round-trip latency (ราวหลักสิบ ms) และถ้า replica ติดต่อไม่ได้ การเขียนจะค้าง **Asynchronous:** primary commit ในพื้นที่และส่งการเปลี่ยนแปลงทีหลัง — เขียนเร็ว แต่การเสีย region สามารถทำให้เสียไม่กี่วินาทีสุดท้าย (**RPO > 0**) cross-region sync มักช้าเกินไป หลายคนจึงรัน async และยอมรับ RPO เล็ก ๆ

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** ข้อมูลที่คุณเสียได้เท่าไร — กำหนดโดย sync vs async
- **RTO (Recovery Time Objective):** นานแค่ไหนกว่าจะกลับมา — กำหนดโดยว่าคุณตรวจจับ failure และ promote เร็วแค่ไหน
- Failover = ตรวจจับ (health check) → promote standby → repoint traffic (DNS/global LB) ทำอัตโนมัติ แต่ป้องกัน **split-brain** (ทั้งสอง region คิดว่าตัวเองเป็น primary) ด้วย quorum/fencing token

## มุมมองการสัมภาษณ์

สิ่งที่จี้: คุณเข้าใจหรือไม่ว่า HA/DR คือ **การแลกเปลี่ยนระหว่าง consistency, latency และการสูญเสียข้อมูล** — ไม่ใช่ "แค่เพิ่ม replica" ดี: active-passive พร้อม standby เยี่ยม: คุณระบุ RPO/RTO, นัยของ sync-vs-async และความเสี่ยง split-brain กับดัก: อ้างว่า async ให้การสูญเสียข้อมูลเป็นศูนย์ หรือสมมติว่า failover ทันทีและไม่มีการสูญเสีย

## ข้อแลกเปลี่ยน & failure

- **Split-brain:** network partition promote สอง primary → ข้อมูลแยกจากกัน ใช้ quorum, fencing หรือ witness region
- **Failback ยาก:** หลัง primary เดิมกลับมา การกระทบยอดการเขียนที่แยกจากกันเป็นงาน manual และผิดพลาดง่าย
- **ต้นทุน:** multi-region จริงเพิ่ม infra ราวสองเท่าและเพิ่มค่า cross-region egress bandwidth
- **Failover ที่ไม่ทดสอบล้มเหลว:** DR ที่ไม่เคยซ้อมจะไม่ทำงานใน outage จริง — รัน game-day

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & failure

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