สถาปัตยกรรม event-driven ในไมโครเซอร์วิสคืออะไร?

Question

Accepted Answer

ในสถาปัตยกรรม **event-driven** บริการสื่อสารโดย **สร้างและบริโภคเหตุการณ์** ผ่าน broker (Kafka, RabbitMQ ฯลฯ) บริการประกาศว่ามีอะไรเกิดขึ้น บริการที่สนใจจึงทำปฏิกิริยา — ผู้สร้างไม่รู้หรือไม่รอพวกเขา

## วิธีการทำงาน

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## ตัวอย่าง event payload

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## ประโยชน์

- **ระบบหลวม** — เพิ่มผู้บริโภคใหม่โดยไม่สัมผัสผู้สร้าง
- **ความแข็งแรง** — broker บัฟเฟอร์เหตุการณ์ระหว่างการหยุดชะงัก
- **ความสามารถในการปรับขนาด** — ผู้บริโภคปรับขนาดอย่างอิสระ

## ข้อเสีย

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## เหตุใดจึงสำคัญ

การออกแบบ event-driven ช่วยให้คุณเพิ่มความสามารถ (การวิเคราะห์ การตรวจสอบการฉ้อฉล การแจ้งเตือน) ด้วยการสมัครสมาชิกอย่างง่าย โดยไม่มีการเปลี่ยนแปลงอย่างใดอย่างหนึ่งกับผู้สร้างที่มีอยู่

การขยายและความแข็งแรงนี้มาพร้อมกับราคาของความสอดคล้องในที่สุดและการดีบักที่ยากขึ้น — การแลกเปลี่ยนตามศูนย์กลางที่คุณยอมรับเมื่อไปใช้ event-driven