ปัญหาที่มักจะตามมาจากระบบที่พัฒนาตามแนวคิด Event-based driven
หรือ Event-Driven Architecture นั่นคือ
เรื่อง Data consistency หรือความถูกต้องของข้อมูล
เราจะจัดการปัญหานี้ได้อย่างไรบ้าง ?
ในการออกแบบระบบตามแนวคิดนี้
ช่วยให้ส่วนการทำงานต่าง ๆ แยกออกจากกัน
หรือไม่ผูกมัดกันมากนัก (loose/less couple)
แต่ละส่วนการทำงานทดสอบได้ง่ายขึ้น
ลดปัญหาเรื่อง single point of failure
สามารถ scale ได้ง่ายขึ้น จะได้ไม่เป็นคอขวดของระบบ
ยกตัวอย่างของระบบงานแบบง่าย ๆ
- Producer คือฝั่ง subscription service จากผู้ใช้งาน
- Consumer คือฝั่ง newsletter service เพื่อส่ง email ไปยัง user ที่ subscribe ไว้
จากรูปถ้าทำงานแบบปกติ คือ success case จะไม่มีปัญหาอะไร
แต่สิ่งที่ต้องคิดและออกแบบไว้เสมอคือ ปัญหาที่อาจจะเกิดขึ้นได้
เราจะแก้ไข หรือ หาวิธีการรองรับไว้อย่างไร
ตัวอย่างของปัญหาที่อาจจะเกิดขึ้นได้
- ข้อมูลบันทึกที่ database ของ subscription service เรียบร้อย แต่ไม่สามารถส่งไปยัง message broker ได้ ทำให้ไม่มีข้อมูลใน newsletter service นี่คือข้อมูลหาย
- ข้อมูลไม่สามารถบันทึกใน database ของ subscription service ได้ แต่ดันส่งไปที่ newsletter service ได้ซะงั้น แบบนี้ก็ไม่น่าจะถูกต้อง
- อาจจะเกิดการส่ง event ซ้ำมายัง message broker ได้ ส่งผลให้ข้อมูลที่ newsletter service ซ้ำอีก
สิ่งที่ต้องคิดต่อคือ ถ้าเกิดปัญหาเหล่านี้ขึ้นมาจะแก้ไขอย่างไร
ก่อนอื่นต้องมีระบบ monitoring หรือ observability ก่อนว่า
มีปัญหาเกิดขึ้นหรือไม่ ทั้ง Application metric, Distributed tracing และ Centralized logging
รวมไปถึงพวก alert system จากปัญหาที่เกิดขึ้น
เพื่อทำให้เราเข้าไปยังจุดเกิดปัญหาได้รวดเร็ว
ต่อมาคือ การออกแบบเพื่อป้องกันปัญหา ไม่ให้เกิดขึ้น หรือ เกิดน้อยสุด ๆ
- ถ้าส่งไปยัง message broker ไม่ได้ ก็ต้องพยายามส่งให้สำเร็จ หรือ ต้องมีการบันทึกสถานนะของการส่งไว้ว่า ส่งไม่ได้
- ถ้าฝั่ง consumer ได้รับ event/message แล้วแต่ process ไม่สำเร็จ จำเป็นต้องจัดการ ไม่ว่าจะเป็นการ retry หรือ dead letter message หรือ แจ้งกลับไปยัง producer ว่าไม่สามารถ processได้นะ
- ถ้าฝั่ง producer ไม่สามารถบันทึกได้ ต้องไม่ส่งไปยัง message broker
- ถ้ามีการส่ง event/message เดิมเข้ามายัง message broker แล้ว ทาง consumer นั้นก็การันตีว่า จะไม่ทำการ process ซ้ำ หรือ ทำซ้ำก็ได้แต่ผลการทำงานก็จะเหมือนทำงานครั้งเดียว นั่นคือ เรื่องของ Idempotent นั่นเอง
ลองดูครับ มีข้อดีก็มีข้อเสียเช่นกัน
ที่เราต้องคิด ออกแบบ และ วางแผน เพื่อรับมือเช่นเดียวกัน
มันไม่ใช่งานงอก แต่เป็นงานที่มันมีอยู่แล้ว
อยู๋ที่ว่าเราจะหยิบมาคุยกันตอนไหนต่างหาก
Reference Websites
