ออกแบบ decoupled และ event-driven
รวมแนวคิดทั้งหมดเป็นสถาปัตยกรรมที่ยืดหยุ่น
แทนที่จะเอาเชือกมาผูกขานักวิ่งทุกคนติดกัน (Tightly Coupled - คนนึงล้มล้มหมด) เราเปลี่ยนมาใช้การวิ่งผลัด (Decoupled) เมื่อคนแรกวิ่งเสร็จก็ส่งสัญญาณหรือไม้ผลัด (Event) ให้คนต่อไปวิ่งต่อ คนที่เหลือก็ทำหน้าที่ของตัวเอง
การสร้างแอปพลิเคชันแบบ Decoupled (แยกส่วนและทำงานเป็นอิสระต่อกัน) และ Event-Driven (ตอบสนองเมื่อเกิดเหตุการณ์) ช่วยให้ระบบยืดหยุ่นสูง ถ้าส่วนใดพัง ส่วนอื่นก็ยังรันต่อได้ และสามารถเพิ่มสเปก (Scale) แยกเฉพาะส่วนที่ใช้งานหนักได้
- ใช้ SQS คั่นกลางเป็นกันชน เพื่อรองรับโหลดที่พุ่งขึ้น (Spike) และป้องกันข้อมูลหาย
- ใช้ SNS เพื่อกระจายข้อความเดียว (Fan-out) ให้หลายๆ บริการพร้อมกัน
- ใช้ EventBridge กรองและส่งต่อเหตุการณ์ (Route Event) อย่างชาญฉลาดในระบบ Event-Driven
- ผลลัพธ์: ระบบมีความยืดหยุ่น (Loosely coupled), ขยายสเกลได้ง่ายขึ้น, และทนทานขึ้น
สรุป Key Takeaways
- Decoupling = แต่ละส่วนล่ม/สเกลได้อิสระ ทนทานขึ้น
- SQS (คิว), SNS (fan-out), EventBridge (route) เป็นเครื่องมือหลัก
คำถามที่พบบ่อย
Event-driven architecture ดีกว่าเรียก API ตรงๆ (synchronous) ยังไง
สามข้อหลัก: decoupling (ผู้ส่งไม่ต้องรู้จัก/รอผู้รับ — ระบบหนึ่งล่มอีกระบบยังรับงานต่อได้), scale อิสระ (คิวดูดซับ spike แทน backend), และเพิ่มผู้บริโภค event ใหม่ได้โดยไม่แก้ผู้ส่ง — แลกกับความซับซ้อนเรื่อง eventual consistency ที่ต้องยอมรับ
Idempotency สำคัญยังไงกับระบบ event-driven
เพราะการส่งแบบ at-least-once ทำให้ข้อความมาซ้ำได้ — consumer ต้องออกแบบให้ประมวลผลซ้ำแล้วผลเหมือนเดิม (เช็ค id ก่อนทำ, ใช้ conditional write) ไม่งั้นเจอปัญหาแบบหักเงินลูกค้าสองรอบ — เป็นหลักที่ข้อสอบเริ่มถามบ่อยขึ้น
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที