เมื่อทำงานข้ามเซอร์วิส โดยทั่วไปคุณจะแลก consistency แบบ strong กับ consistency แบบ eventual และพึ่งพา CQRS กับ event sourcing เพื่อให้แนวทางนี้ใช้งานได้จริงและถูกต้อง
หลังจากมีการเปลี่ยนแปลง replica ต่าง ๆ จะ converge เข้าหากันใน "อีกไม่นาน" แทนที่จะทันทีทันใด ซึ่งยอมรับได้สำหรับ business flow ส่วนใหญ่ (จำนวน inventory อาจล่าช้าไปสักวินาที) แต่ยอมรับไม่ได้สำหรับบางกรณี (การตรวจสอบยอดเงินในบัญชีธนาคาร)
แยก write model ออกจาก read model หนึ่งตัวหรือมากกว่า
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
ฝั่ง read สามารถ scale และปรับรูปร่าง (reshape) ได้อย่างอิสระจากฝั่ง write โดย read model จะถูกอัปเดตจาก event ดังนั้นจึงเป็นแบบ eventually consistent
เก็บ ลำดับของ event เป็น source of truth ไม่ใช่แค่ current state เพียงอย่างเดียว โดย current state คือการ fold ทับ event ทั้งหมด
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| เทคนิค | สิ่งที่ได้ | ต้นทุน |
|---|---|---|
| Eventual consistency | ความพร้อมใช้งาน, การ scale | อ่านได้ข้อมูลเก่า (stale), เกิด conflict |
| CQRS | scale ทั้งฝั่ง read/write | มีสองโมเดลที่ต้อง sync ให้ตรงกัน |
| Event sourcing | audit, replay, ประวัติ | การ evolve schema/event, ความซับซ้อน |
อย่านำ event sourcing ไปใช้ทุกที่ — มันทรงพลังแต่ก็หนักหน่วง ใช้มันในจุดที่ audit/ประวัติมีความสำคัญอย่างแท้จริง
ระบบ distributed ไม่สามารถมีทั้ง strong consistency, availability และ partition tolerance พร้อมกันได้ทั้งหมด ดังนั้นการออกแบบในระดับ senior จึงเป็นเรื่องของการเลือกว่าจุดใดที่ eventual consistency เป็นที่ยอมรับได้
CQRS และ event sourcing มอบเครื่องมือให้คุณทำให้ eventual consistency มีความน่าเชื่อถือและตรวจสอบย้อนหลังได้ — แต่แต่ละอย่างก็เพิ่มความซับซ้อนที่แท้จริง จึงควรนำไปใช้อย่างเจาะจง ไม่ใช่ใช้เป็นค่าตั้งต้นเสมอ