Cron Job API และ Webhook ระบบการเงิน: การรับประกันการส่งข้อมูล

บทเรียนจากการออกแบบระบบการเงินในกลุ่มธุรกิจเฮลท์เทคชี้ให้เห็นว่า การเลือกใช้เครื่องมือตั้งเวลา (Scheduler) ควรพิจารณาจากสัญญาการส่งมอบข้อมูลที่พิสูจน์ได้ มากกว่าความง่ายของตัวแก้ไข Cron โดยสำหรับรายงานประจำวันที่ใช้ตรวจสอบยอดชำระเงิน สัญญาที่มีประโยชน์มักเป็นการทำงานแบบ at-least-once ควบคู่ไปกับคีย์รายงานแบบ idempotent โดยมี Webhook ทำหน้าที่ปลุกการทำงาน แต่ไม่ควรใช้ Webhook เป็นสิ่งยืนยันว่าอีเมลถูกส่งไปถึงปลายทางแล้ว

ความแตกต่างดังกล่าวปรับเปลี่ยนแนวทางการออกแบบระบบอย่างสิ้นเชิง รายงานประจำวันอาจล่าช้าได้แต่ต้องยังคงใช้งานได้ ขณะที่กระบวนการตรวจสอบยอดที่พลาดช่วงเวลาของผู้ให้บริการอย่างเงียบๆ ถือเป็นข้อผิดพลาดทางบัญชีที่ยอมรับไม่ได้ ระบบจึงถูกกำหนดให้รันหนึ่งรอบในเวลา 02:00 UTC พร้อมบันทึกประวัติการทำงานแบบแก้ไขไม่ได้ ดึงข้อมูลช่วงเวลาการชำระเงิน สร้างรายงาน และส่งต่องานอีเมลผ่านเส้นทางการยืนยันที่คงทน โดยให้ตัวตั้งเวลาเป็นเพียงตัวกระตุ้น ส่วน Ledger คือผู้มีอำนาจตัดสินใจสูงสุด

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

แนวคิดคำว่า exactly once มักใช้ได้ไม่ดีนักเมื่อกระบวนการต้องครอบคลุมทั้ง HTTP และอีเมล ทางออกที่ดีคือการใช้คีย์ความซ้ำซ้อน (Idempotency Key) เช่น payment-reconciliation:2026-10-24 ระบุวันที่ทางธุรกิจ ขณะที่รหัสความพยายาม (Attempt ID) แยกแต่ละครั้งที่ส่ง หาก Webhook ถูกส่งเข้ามาสามครั้ง ความพยายามทั้งสามจะชี้ไปยังการทำงานเชิงตรรกะเดียวกัน โมเดลการยืนยันรับทราบของ RabbitMQ แสดงให้เห็นขอบเขตที่ชัดเจนว่าผู้บริโภคจะยืนยันเมื่อจัดการข้อความเสร็จสิ้นแล้วเท่านั้น และข้อความที่ยังไม่ได้รับ Acknowledge อาจถูกส่งซ้ำได้ ซึ่งถือเป็นพฤติกรรมการกู้คืนไม่ใช่ข้อบกพร่อง