HTTP Data Cleanup: จัดการข้อมูลด้วยการทริกเกอร์แบบจำกัดขอบเขต

การจัดการข้อมูลเก่าหรือ Data Cleanup ในระบบซอฟต์แวร์ขนาดใหญ่มักเป็นโจทย์ที่สถาปนิกซอฟต์แวร์ต้องขบคิด โดยแนวทางที่น่าสนใจคือการใช้ตัวกระตุ้นภายนอก (External Recurring Trigger) ส่งคำขอ HTTP ขนาดเล็กที่มีการตรวจสอบสิทธิ์ไปยังเอนด์ปอยต์ทำความสะอาดโดยตรง จากนั้นให้เอนด์ปอยต์นั้นทำการจองหน้าต่างเวลาก่อนเริ่มประมวลผล วิธีนี้ช่วยให้ตัวกระตุ้นยังคงสถานะไร้รัฐ (Stateless) และแอปพลิเคชันไม่ต้องพึ่งพาตัวจัดการงานภายในระบบ

สำหรับระบบ B2B SaaS ที่ต้องระบายงานในพูลคนงานที่มีการจำกัดอัตรา (Rate-limited worker pool) ผู้พัฒนามักเริ่มต้นด้วยนโยบายรอบเวลา 5 นาทีและหน้าต่างทำความสะอาด 1 นาที ซึ่งตัวเลขเหล่านี้เป็นเพียงจุดเริ่มต้นไม่ใช่ค่าคงที่ โดยช่วงเวลาที่เหมาะสมจะขึ้นอยู่กับอายุของข้อมูลเก่าที่ยอมรับได้และงบประมาณคำขอที่มีในระบบ คำขอประจำควรทำหน้าที่สั่งให้ระบบขยับเส้นแบ่งการทำความสะอาด (Watermark) แทนที่จะให้ประมวลผลข้อมูลค้างทั้งหมดในครั้งเดียว

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

การเพิ่มหน่วงเวลาเพื่อความปลอดภัย (Safety Delay) ถือเป็นอีกหนึ่งกลไกที่ช่วยรับมือกับความคลาดเคลื่อนของเวลาและข้อมูลที่เข้ามาล่าช้า ตัวอย่างเช่น หากเวลาปัจจุบันคือ 12:05:00 และกำหนดเวลาหน่วงไว้ 2 นาที ระบบจะประมวลผลข้อมูลถึงเวลา 12:03:00 ทำให้รายการที่เข้ามาตอน 12:04:58 ต้องรอรอบถัดไป แทนที่จะเกิดการชนกันกับกระบวนการเขียนข้อมูลเดิม

ในด้านการวัดผลประสิทธิภาพ ไม่ควรใช้ระยะเวลาของคำขอเป็นตัวชี้วัดความหน่วงเพียงอย่างเดียว ทีมพัฒนาควรติดตามความล่าช้าตั้งแต่การทริกเกอร์จนถึงการเคลมข้อมูล อายุของข้อมูลเก่าที่ยังไม่ถูกเคลม ขนาดของหน้าต่างเวลา ความขัดแย้งในการเคลม และจำนวนครั้งในการลองใหม่ เพื่อให้ทราบอย่างแท้จริงว่ารอบเวลาที่สั้นลงช่วยเพิ่มความสดใหม่ของข้อมูลจริง หรือเพียงแค่สร้างปริมาณคำขอที่ไม่จำเป็น

ที่มา: Dev.to