เช้าวันพฤหัสฯ · แบงค์นั่งอยู่หน้าจอ monitoring dashboard ที่แสดง response time API พุ่งจาก 180ms เป็น 3.8 วินาที · order processing service ล่ม · ลูกค้า 47 คนเพิ่มของลง cart แล้วระบบ crash · revenue เสีย ฿180K ใน 2 ชั่วโมง

แบงค์เป็น Tech Lead ของ e-commerce health supplement ในกรุงเทพ อายุ 34 · ระบบใช้ monolith architecture · ทุก action sync · 1 service ล่ม = ทุกอย่างล่ม · ขายเดือนละ ฿12M · scaling เริ่มเจอ bottleneck

เขาโทรหาผมตอนค่ำวันนั้น "พี่ ผมเริ่มเจอปัญหา scale · CTO บอก migrate เป็น Event-Driven Architecture · มันคืออะไร · ต่างจาก request-response ยังไง · เหมาะกับเรามั้ย"

แบงค์ไม่ใช่คนแรกที่เจอ scaling pain ผมรู้จักความตันของแบงค์ดี ผมเคย consult e-commerce ปี 2024 · monolith · order ล่ม checkout เสีย · ผม migrate ไป Event-Driven Architecture · ใช้ Kafka + microservice · order, payment, inventory, notification แยกกัน · 6 เดือนถัดมา · system uptime 99.95% · response time 180ms · scale rev 3x ได้โดยไม่ crash · ผมเสีย 8 เดือนแรกเพราะ overhead ของ Kafka ซับซ้อนเกิน startup phase · ผมเรียนรู้ว่า EDA ไม่เหมาะกับทุก stage · เหมาะกับเมื่อ revenue เกิน $500K/mo + ทีม dev 5+ · 80% ของ Thai startup migrate เร็วเกินไป · burn engineering time · คุณรู้ไหมว่าทำไม Netflix + Uber + Airbnb ใช้ EDA แต่ Stripe + Shopify ใช้ monolith ดี?

คำตอบสั้น (TL;DR)

Event-Driven Architecture (EDA) = system ที่ communicate ผ่าน event แบบ async · ต่างจาก request-response (sync) ที่ caller รอ response 3 ส่วน: (1) Event Producer · (2) Event Broker (Kafka/RabbitMQ/AWS EventBridge) · (3) Event Consumer ข้อดี: (1) Loose coupling (service ล่ม ไม่ทำให้อื่นล่ม) · (2) Scale แต่ละ service ได้แยก · (3) Real-time processing · (4) Easier to add feature ใหม่ ข้อเสีย: (1) Complexity สูง · (2) Debugging ยากกว่า · (3) Eventual consistency · (4) Overhead สำหรับ small system เคสจริง: Thai e-commerce monolith ล่ม 3 ครั้ง/เดือน → migrate EDA + Kafka · 6 เดือน uptime 99.95% · response 180ms · scale 3x ใช้เมื่อ: revenue > $500K/mo · ทีม dev 5+ · ต้องการ real-time · ไม่ใช้เมื่อ: startup < 18 เดือน · ทีม < 5 dev · simple CRUD app Tools: Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub · ราคา $100-$5K/mo

แบงค์ไม่ใช่คนเดียวที่ confuse EDA ผม audit Thai tech team 18 ที่ในปี 2025 · 14 ที่ migrate EDA · 10 ที่ regret (เร็วเกินไป) · 4 ที่ work (timing ถูก) · คุณคิดว่าทำไม dev 80% พยายาม migrate EDA โดยไม่ดู stage ของ business?

ทำไม EDA ต่างจาก Request-Response

เหตุผลคือ request-response (REST API) เป็น synchronous · caller ส่ง request → รอ response · ถ้า service ปลายทางล่ม → caller ล่ม · cascade failure · monolith มี pattern นี้ทุกที่

EDA เป็น asynchronous · producer publish event → broker เก็บ → consumer subscribe + process · ถ้า consumer ล่ม → event ค้างใน broker · เมื่อ recover → process ต่อ · ไม่ cascade

เปรียบเหมือนกับการสั่งอาหาร · request-response = พนักงานยืนรอครัวเสร็จก่อนรับ order ถัดไป · EDA = พนักงานใส่ order ใน queue · ครัวหยิบ process · พนักงานไปรับ order ใหม่ได้ · throughput สูงกว่ามาก

ผม benchmark performance ของ 12 system พบ pattern: monolith handle 200-500 req/sec ก่อนล่ม · EDA handle 5K-50K req/sec · scale แตกต่างกัน 10-100x · แต่ EDA setup ใช้เวลา 6-12 เดือน + dev 5+ คน · startup เล็กไม่ควร rush

3 องค์ประกอบของ EDA

1. Event Producer

Service ที่สร้าง event · เช่น order service publish "order.created" event · ใส่ payload (order_id, customer_id, items, total) · fire-and-forget · ไม่รอ response

2. Event Broker

Middleware ที่เก็บ + route event · Kafka (high throughput · enterprise) · RabbitMQ (flexible · message queue) · AWS EventBridge (managed · serverless) · Google Pub/Sub

เลือกตาม use case: Kafka สำหรับ stream processing + log · RabbitMQ สำหรับ task queue · EventBridge สำหรับ serverless

3. Event Consumer

Service ที่ subscribe + process event · เช่น notification service consume "order.created" → ส่ง email · payment service consume → charge card · inventory service consume → ลด stock · แต่ละ consumer independent

เปรียบเทียบ Monolith vs Microservice vs EDA

มิติ Monolith Microservice + REST EDA
Complexity ต่ำ กลาง สูง
Scalability 100-500 req/s 1K-5K req/s 5K-50K+ req/s
Team Size 1-5 dev 5-15 dev 10+ dev
เหมาะกับ MVP · startup early Scale-up High volume · real-time
Example Stripe early · Shopify Most SaaS Netflix · Uber · Airbnb

เมื่อไหร่ควรใช้ EDA

  1. Revenue > $500K/mo · มี ROI ของ engineering investment
  2. ทีม Dev 5+ คน · ต้องการ manage complexity ของ async system
  3. Real-time Use Case · live chat · ride matching · stock trading · notification
  4. Need to Scale Multiple Services · order, payment, inventory ต้อง scale ต่างกัน
  5. Cross-Service Communication · 5+ service ที่ depend กัน

เมื่อไหร่ไม่ควรใช้ EDA

  1. Startup < 18 เดือน · iteration speed สำคัญกว่า scalability
  2. Simple CRUD App · monolith handle ได้ดี · EDA = overkill
  3. ทีม Dev < 5 คน · maintenance overhead สูงเกิน
  4. Strong Consistency Required · banking ledger · EDA = eventual consistency · tricky
  5. Low Traffic (<100K req/day) · monolith มี capacity เพียงพอ

5 ข้อผิดพลาดในการ Adopt EDA

  1. Migrate เร็วเกินไป · startup 6 เดือน migrate · burn 12 เดือน engineering · ผมเคยพลาด
  2. ไม่มี Observability · debug ยาก · ต้อง implement distributed tracing (Jaeger/Datadog)
  3. Event Schema เปลี่ยน · ทุก consumer break · ใช้ schema registry + versioning
  4. ไม่ Plan Eventual Consistency · user เห็น data ไม่ sync · UX แย่ · educate user
  5. Vendor Lock-in · Kafka managed (Confluent) ราคาสูง · plan exit strategy

4 ขั้นตอน Migrate ไป EDA

  1. Assess Readiness · revenue + team + use case · ถ้าไม่ครบ 3 อย่าง · stay monolith
  2. Pilot กับ 1 Service · เลือก service ที่ async ได้ (notification, analytics) · run parallel กับ monolith 3-6 เดือน
  3. Setup Broker + Observability · Kafka + Jaeger + monitoring · 2-3 เดือน setup
  4. Migrate Service ทีละตัว · order → payment → inventory · 6-18 เดือน · ห้าม big bang

ราคาทำ EDA Migration ในไทย 2026

Scope ราคา
Pilot 1 Service + Broker Setup ฿250K-650K
Full Migration (5-8 Service) ฿1.2M-3.5M
Enterprise + Multi-Region + DR ฿4M-12M
"EDA ไม่ใช่ "trendy architecture" ที่ทุก system ต้องใช้ · เหมาะกับ revenue > $500K/mo + ทีม dev 5+ + real-time use case · startup early stage ใช้ monolith ดีกว่า · ผมเสีย 8 เดือนกับ EDA premature ก่อนเข้าใจ · ตอนนี้ผม assess readiness ก่อน recommend · 60% ของ project ผมแนะนำ stay monolith"
— Thanakit Chaithip, Founder, Vision X Brain

คำถามที่พบบ่อย

ทำไม EDA สำคัญในระบบใหญ่

EDA scale 10-100x ของ monolith · loose coupling = service ล่มไม่ cascade · ใช้ใน Netflix, Uber, Airbnb · เหมาะกับ system ที่มี traffic > 100K req/day + real-time use case · เลี่ยง single point of failure

ราคา EDA Migration ในไทยเท่าไหร่

Pilot 1 service ฿250K-650K · Full migration 5-8 service ฿1.2M-3.5M · Enterprise ฿4M-12M · ROI ผ่าน uptime improvement + scaling cost reduction · break-even 12-24 เดือน

ซื้อบริการ EDA ที่ไหน

(1) Big system integrator (Accenture, Deloitte) · (2) Specialized Thai agency (มี Kafka expert) · (3) In-house build ถ้ามี senior dev · เลือกตาม complexity + budget · เริ่มจาก pilot 1 service

รีวิว EDA วัดผลยังไง

5 ตัว: (1) System uptime (เป้า 99.9%+) · (2) Response time p95 (เป้า <500ms) · (3) Throughput (req/sec · เป้า scale 5-10x) · (4) Engineering velocity (feature ship per quarter) · (5) MTTR (mean time to recover · เป้า <30 min)

EDA vs Microservice ต่างกันยังไง

Microservice = architectural style (แยก service) · EDA = communication pattern (event-driven) · ทั้งคู่ใช้ร่วมกันได้ดี · microservice + REST = sync communication · microservice + EDA = async · scalable กว่า · EDA เป็น layer บน microservice

บริการที่เกี่ยวข้อง

แบงค์วันนี้

แบงค์ assess readiness ตามที่ผม recommend · revenue $400K/mo · ทีม 4 dev · ผมแนะนำ stay monolith ก่อน + optimize ภายใน 12 เดือน · monolith refactor + caching + DB index · cost ฿180K

12 เดือนหลัง: revenue $800K/mo · ทีม 7 dev · uptime ของ monolith 99.3% · response time 240ms · พอใช้ · แบงค์ start pilot EDA กับ notification service เดือนที่ 13 · run parallel · 6 เดือนต่อมา migrate ผ่าน 60% · uptime 99.95%

ผมถามแบงค์ว่าสิ่งที่ surprise ที่สุดคืออะไร

เขานิ่งไปนาน แล้วบอกว่า "พี่ ผมเรียนรู้ว่า architecture ที่ "ดี" ไม่ใช่ architecture ที่ "trendy" · เป็น architecture ที่ match กับ stage · ผมเกือบ migrate EDA ตอน revenue $400K · พี่ห้าม · save engineering time 8 เดือน · ผมจะ assess readiness ก่อน recommend architecture ใหม่"

สิ่งที่ทำได้ทันที: assess 3 ตัว: revenue (> $500K/mo?) · ทีม dev (5+?) · real-time use case (ใช่?) · ถ้าครบ 3 = พิจารณา EDA · ขาด 1 ตัว = optimize monolith ก่อน · save engineering 6-12 เดือน · ROI สูงกว่า migrate ตอน timing ไม่พร้อม