Saga pattern คืออะไร และการ orchestration แตกต่างจาก choreography อย่างไร

Question

Accepted Answer

**Saga** จัดการธุรกรรมทางธุรกิจที่ขยายไปยังหลายบริการเป็นลำดับของ **ธุรกรรมเฉพาะที่** หากขั้นตอนใดล้มเหลว saga จะเรียกใช้ **ธุรกรรมชดเชย** เพื่อยกเลิกขั้นตอนก่อนหน้า — ไม่มีการ rollback แบบกระจาย

## เหตุใดจึงไม่ใช่ธุรกรรมแบบกระจาย

การ commit สองขั้นตอนข้ามบริการช้า ล็อกทรัพยากร และเชื่อมโยงความพร้อมใช้งาน Sagas ให้ความสอดคล้องขั้นสุดท้ายโดยไม่มีการล็อกแบบกระจาย

## Choreography (event-driven)

บริการตอบสนองต่อเหตุการณ์ของกันและกัน ไม่มีประสานงานตรงกลาง

```text
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
   ◀───────── (on failure, each emits a compensating event) ─────────
```

## Orchestration (ประสานงานตรงกลาง)

Orchestrator บอกให้บริการแต่ละบริการรู้ว่าต้องทำอะไร และตอบสนองต่อผลลัพธ์

```text
        ┌───────────── Saga Orchestrator ─────────────┐
        ▼              ▼              ▼                ▼
   reservePayment  reserveStock  createShipment   (on fail: compensate all)
```

## เปรียบเทียบ

| ด้าน | Choreography | Orchestration |
|---|---|---|
| การประสานงาน | แบบกระจาย (เหตุการณ์) | แบบรวมศูนย์ |
| การเชื่อมโยง | หลวมมากขึ้น | ประสานงานรู้การไหลของข้อมูล |
| ความมองเห็น | ยากที่จะติดตาม | ติดตามได้ง่าย |
| เหมาะสมที่สุดสำหรับ | เรียบง่าย ขั้นตอนน้อย | ซับซ้อน ขั้นตอนมากมาย |

## ข้อขัดข้อง

การชดเชยต้อง **idempotent** และจัดการกรณีที่ขั้นตอนเดิมสำเร็จบางส่วน ออกแบบอย่างระมัดระวัง

## ทำไมจึงมีความสำคัญ

Sagas คือวิธีที่คุณรักษาความสอดคล้องของข้อมูลข้ามบริการโดยไม่มีต้นทุนและการเชื่อมโยงของธุรกรรมแบบกระจาย

การเลือกระหว่าง choreography และ orchestration นั้น trade-off ความเรียบง่ายสำหรับความมองเห็น: เหตุการณ์ขยายตัวอย่างหลวม แต่กลายเป็นยุ่งเหยิง ในขณะที่ orchestrator รวมศูนย์ตรรกะที่ซับซ้อนโดยใช้ต้นทุนของส่วนประกอบอีกหนึ่งในการเรียกใช้

ด้าน	Choreography	Orchestration
การประสานงาน	แบบกระจาย (เหตุการณ์)	แบบรวมศูนย์
การเชื่อมโยง	หลวมมากขึ้น	ประสานงานรู้การไหลของข้อมูล
ความมองเห็น	ยากที่จะติดตาม	ติดตามได้ง่าย
เหมาะสมที่สุดสำหรับ	เรียบง่าย ขั้นตอนน้อย	ซับซ้อน ขั้นตอนมากมาย