Event-Driven Architecture (EDA) คือการออกแบบระบบที่สื่อสารกันด้วย “เหตุการณ์” (event) จากผู้สร้าง (producer) ผ่านตัวกลางอย่าง broker ไปยังผู้บริโภค (consumer) ที่สนใจ ช่วยแยกส่วน (decouple) สเกลง่าย รองรับเรียลไทม์ แต่ต้องจัดการความสอดคล้องแบบท้ายสุด (eventual consistency) และการสังเกตการณ์ให้ดี
Event-Driven Architecture คืออะไร? หลักการ องค์ประกอบ และวิธีเริ่มต้น
สำหรับทีม Product/Platform/Integration EDA ช่วยให้บริการต่าง ๆ สื่อสารกันแบบหลวม ลดการพึ่งพากันโดยตรง และตอบสนองเหตุการณ์ได้ทันที เช่น ชำระเงินสำเร็จ → ส่งอีเมล → ออกใบเสร็จ → อัปเดตสต็อก โดยไม่ต้องเรียก API ต่อกันเป็นห่วงโซ่ยาว
องค์ประกอบสำคัญ
| องค์ประกอบ | หน้าที่ | ตัวอย่างเทคโนโลยี |
|---|
| Event |
ข้อเท็จจริงที่เกิดขึ้นแล้ว (immutable) บรรยาย “อะไรเกิดขึ้น เมื่อไร ที่ไหน โดยใคร” |
CloudEvents สคีมามาตรฐาน |
| Producer |
แอป/บริการที่เผยแพร่เหตุการณ์ |
Checkout Service, IoT Device |
| Broker / Bus |
ตัวกลางกระจายเหตุการณ์ เก็บบัฟเฟอร์/รีเพลย์ |
Apache Kafka, AWS SNS/SQS, Google Pub/Sub, Azure Event Hubs |
| Consumer |
บริการที่สมัครรับ (subscribe) แล้วประมวลผล |
Billing, Notification, Analytics |
เปรียบเทียบกับสถาปัตยกรรมเรียกตอบ (Request–Response)
| มิติ | EDA (Event-Driven) | Request–Response (REST/RPC) | ควรใช้เมื่อ |
|---|
| การเชื่อมต่อ |
หลวมผ่าน broker, กระจายหลายผู้บริโภค |
พึ่งพากันโดยตรง, synchronous |
EDA: หลายผู้ฟัง, ต่อขยายบ่อย / RR: ธุรกรรมเดี่ยวแบบทันที |
| สเกล |
รับโหลดพีกผ่านคิว/พาร์ทิชัน |
สเกลได้แต่เสี่ยงคอขวดที่บริการปลายทาง |
EDA: พีกไม่คาดเดา / RR: SLA ที่ต้องตอบเดี๋ยวนี้ |
| ความสอดคล้อง |
สุดท้าย (eventual), ต้องออกแบบชดเชย (saga) |
มักสอดคล้องทันที (stronger) |
EDA: pipeline ต่อเนื่อง / RR: เงินเข้าเงินออกทันที |
| การสังเกตการณ์ |
ต้องตั้ง trace/log/metric แบบ end-to-end |
ติดตามง่ายกว่าในสายเดียว |
EDA: มีหลาย consumer / RR: เส้นทางสั้น |
แพทเทิร์นยอดนิยม
- Publish/Subscribe: Producer ส่ง event 1 ครั้ง หลาย consumer รับตามความสนใจ
- Event Sourcing: เก็บสถานะระบบจากลำดับเหตุการณ์ทั้งหมด รีเพลย์เพื่อสร้างสถานะปัจจุบัน
- Saga: ประสานธุรกรรมกระจายด้วยชุด event และ compensating actions
- Outbox Pattern: เขียนข้อมูลธุรกรรมและ event ลงตารางเดียวกัน แล้วดึงไปเผยแพร่อย่างน่าเชื่อถือ
ตัวอย่าง Payload (CloudEvents JSON)
{
"specversion": "1.0",
"type": "com.shop.payment.succeeded",
"source": "/payments/checkout",
"id": "7f0c2d3e-4b2c-4c57-9f9a-1a2b3c4d5e6f",
"time": "2025-08-24T07:21:00Z",
"datacontenttype": "application/json",
"subject": "order_874213",
"data": {
"orderId": "874213",
"amount": 1299.00,
"currency": "THB",
"method": "card",
"customerId": "c_10293"
}
}
เช็กลิสต์ออกแบบ EDA ให้ “เวิร์กจริง”
| หัวข้อ | สิ่งที่ต้องทำ | เหตุผล |
|---|
| สคีมา Event |
กำหนดชนิด/คีย์/เวลา/แหล่งที่มา และเวอร์ชัน |
ป้องกันแตกหักเมื่ออัปเดตสคีมา |
| Idempotency |
ออกแบบ consumer ให้ประมวลผลซ้ำได้ปลอดภัย |
คิว/รีไทร์อาจส่งซ้ำ |
| Ordering |
ใช้คีย์พาร์ทิชันที่เหมาะ หรือเก็บเวอร์ชันสถานะ |
รักษาลำดับสำหรับแต่ละ entity |
| DLQ/Retry |
กำหนด backoff, เดดเลตเตอร์คิว, alert |
แยกงานเสีย/วิเคราะห์ภายหลัง |
| Observability |
Trace id กระจาย, metric ต่อหัวข้อ (topic), log |
ดีบักข้ามบริการได้ |
| Security |
เข้ารหัส, IAM, แยกเนมสเปซ by env/team |
ลด blast radius |
ตัวอย่างสถาปัตยกรรม (ย่อ)
- Checkout (Producer) → ส่ง
payment.succeeded ไปยัง payments topic
- Consumers: Billing, Email, Inventory, Analytics
- Broker: Kafka/SNS+SQS/Pub/Sub (เลือกตามระบบนิเวศและ SLA)
- รองรับรีเพลย์, DLQ, Metric/Trace ข้ามบริการ
HowTo: เริ่มใช้ EDA ใน 6 ขั้น
- ระบุ “เหตุการณ์ธุรกิจ” สำคัญและขอบเขตทีม/โดเมน
- ออกแบบสคีมาตาม CloudEvents + ตั้งเวอร์ชันนิ่ง
- เลือก broker ตามโหลด/SLA/ระบบนิเวศ (Kafka หรือคลาวด์)
- ทำ Outbox + Idempotency + DLQ/Retry
- ตั้ง Observability (trace/log/metric) และทดสอบรีเพลย์
- วัดผล (เวลา end-to-end, อัตราล้มเหลว, ค่าใช้จ่าย) แล้ว iterate
บริการที่เกี่ยวข้อง (Internal Links)
อ่านต่อ (บทความที่เกี่ยวข้อง)
อ้างอิงภายนอก (E-E-A-T)
เกี่ยวกับผู้เขียน
Vision X Brain Team — ทีม Website/SEO/CRO & Webflow สำหรับธุรกิจ เราช่วยออกแบบข้อมูล/สคีมา วางโครงสร้างภายใน และยกระดับประสิทธิภาพเว็บ–แอปให้วัดผลได้จริง
อัปเดตล่าสุด: 24 Aug 2025
