Node.js ระบบแจ้งเตือน SMS คำสั่งซื้อสหรัฐฯ และยุโรป
เจาะลึก 3 ข้อแลกเปลี่ยนของ Polling API ในระบบเฮลท์เทค สำหรับส่งใบเสร็จผ่าน SMS ทั้งในสหรัฐฯ และยุโรป พร้อมการจัดการเทมเพลตฝั่งแอปพลิเคชัน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เลือก SMS API แบบส่งและเช็คสถานะผ่าน Polling เมื่อแอปพลิเคชันดูแลเทมเพลตเอง
- ระบบสถานะต้องรัดกุม รองรับการทำ Idempotency ป้องกันการส่งซ้ำเมื่อเกิดเหตุระบบจ่ายเงินรอดำเนินการซ้ำซ้อน
- การจัดการประเทศ กฎการบล็อก และนโยบายการส่งข้อความต้องอยู่ฝั่งแอปพลิเคชัน ไม่ใช่ผู้ให้บริการ
การพัฒนาระบบเฮลท์เทคที่ต้องการส่งใบเสร็จผ่านข้อความ SMS ทันทีหลังจากการชำระเงินสำเร็จ ความท้าทายสำคัญไม่ได้อยู่ที่การตั้งค่าฟังก์ชันใน SDK แต่เป็นการตัดสินใจว่าใครควรเป็นผู้ถือครองเทมเพลตข้อความ หากทีมพัฒนาต้องการควบคุมเนื้อหา ภาษา และประวัติการอนุมัติด้วยตัวเอง การเลือกใช้บริการ SMS API แบบพื้นฐานที่มีระบบส่งและตรวจสอบสถานะผ่าน Polling ย่อมตอบโจทย์กว่า แต่หากระบบต้องการการแจ้งเตือนแบบเรียลไทม์เพื่อรับมือกับเหตุการณ์เร่งด่วน ผู้พัฒนาจำเป็นต้องมองหาผู้ให้บริการที่มีระบบ Event Push แทน
ความแตกต่างนี้มีความสำคัญอย่างยิ่งต่อการดำเนินงานทั้งในตลาดสหรัฐอเมริกาและสหภาพยุโรป แม้ใบเสร็จรับเงินจะเป็นธุรกรรมมาตรฐาน แต่ขั้นตอนการทำงานเบื้องหลังยังคงต้องรับมือกับปัญหาที่หลากหลาย เช่น เครือข่ายปฏิเสธหมายเลขโทรศัพท์ ผู้ป่วยเปลี่ยนเบอร์มือถือ หรือความเสี่ยงที่การส่งข้อความซ้ำจะทำให้เกิดข้อความเบิ้ล ดังนั้น ทีมพัฒนาจึงควรตกลงเรื่องการเป็นเจ้าของเทมเพลตให้ชัดเจนก่อนที่จะเปรียบเทียบผู้ให้บริการรายอื่น
การบริหารจัดการเทมเพลตฝั่งแอปพลิเคชันช่วยให้ทีมพัฒนาสามารถควบคุมเวอร์ชันของข้อความและบันทึกประวัติการตรวจสอบย้อนหลังได้อย่างแม่นยำ เหมาะกับระบบที่ต้องการเก็บบันทึกข้อมูลการทำธุรกรรมอย่างโปร่งใส แต่มีข้อแลกเปลี่ยนคือทีมงานต้องรับภาระในการสร้างระบบ Polling และนโยบายการลองส่งซ้ำ (Retry Policy) ด้วยตนเอง
เมื่อแอปพลิเคชันเป็นผู้ควบคุมเทมเพลต ข้อความ ตัวเลือกภาษา และประวัติการอนุมัติจะถูกเก็บไว้ที่ระบบภายในทั้งหมด บริการ SMS จะทำหน้าที่รับข้อความที่เรนเดอร์เสร็จแล้วพร้อมปลายทางเท่านั้น ซึ่งช่วยสร้างขอบเขตที่ชัดเจนระหว่างระบบชำระเงินและระบบจัดส่งข้อความ โดยมีแนวทางปฏิบัติที่แนะนำดังนี้
- รักษาสถานะของข้อความให้เรียบง่ายด้วยสถานะ accepted, delivered, failed หรือกำหนด timeout ที่ชัดเจน
- จัดเก็บ Message ID คู่กับ Order ID, เวอร์ชันเทมเพลต, ประเทศ และเนื้อหาข้อความ
- ใช้ Idempotency Key ที่สร้างจากเหตุการณ์คำสั่งซื้อ เพื่อป้องกันไม่ให้การส่งซ้ำสร้างใบเสร็จที่สองขึ้นมา
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในกรณีที่คำสั่งซื้อถูกส่งซ้ำเนื่องจากระบบประมวลผลการชำระเงินส่งข้อมูลซ้ำซ้อน ระบบควรใช้ Key เดียวกันเพื่อระบุว่าเป็นการส่งข้อความในตรรกะเดิม จากนั้น Polling Worker จะทำหน้าที่อ่านสถานะข้อความและบันทึกผลลัพธ์สุดท้ายลงในไทม์ไลน์ของคำสั่งซื้อ สำหรับหมายเลขโทรศัพท์ในสหภาพยุโรป นโยบายของประเทศปลายทางจะต้องได้รับการตรวจสอบและอนุมัติก่อนที่คำสั่งซื้อจะถูกส่งออกจาก Worker เสมอ
"Polling is adequate when a receipt can be marked delivery pending for a few minutes and a scheduled worker can reconcile it."
Dev.to
ระบบ Polling ถือว่าเพียงพอเมื่อใบเสร็จสามารถถูกกำหนดสถานะเป็นรอดำเนินการเป็นเวลาไม่กี่นาที และปล่อยให้ Worker ที่ตั้งเวลาไว้เข้ามาตรวจสอบซ้ำ อย่างไรก็ตาม วิธีนี้ไม่เหมาะกับกรณีที่ความล้มเหลวในการจัดส่งต้องแจ้งเตือนเจ้าหน้าที่ทันที หรือจำเป็นต้องสลับไปใช้ช่องทางอื่น เช่น เสียงโทรศัพท์หรือแอปพลิเคชันแชท เนื่องจากระบบนี้รองรับเฉพาะช่องทาง SMS เท่านั้น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น