การที่ API ตอบกลับว่าสำเร็จไม่ได้แปลว่าข้อความถึงโทรศัพท์แล้วเสมอไป ระบบที่น่าเชื่อถือควรแยกสถานะของคำขอออกจากสถานะการส่ง และเก็บรหัสอ้างอิงเพื่อเชื่อมเหตุการณ์ตั้งแต่ต้นจนจบ
ให้ระบบสร้าง Message ID ทุกครั้ง แยก Accepted ออกจาก Delivered และ Failed บันทึก Timestamp ของแต่ละเหตุการณ์ และออกแบบการ Retry ให้ไม่ส่งข้อความซ้ำ
แยก Lifecycle ของข้อความให้ชัด
ชื่อสถานะอาจต่างกันตามผู้ให้บริการ แต่แนวคิดหลักควรแยกอย่างน้อยระหว่างรับคำขอแล้ว กำลังประมวลผล ส่งต่อเครือข่าย ส่งสำเร็จ และส่งไม่สำเร็จ
- ✓Accepted: ระบบรับข้อมูลและผ่านการตรวจสอบเบื้องต้น
- ✓Queued/Processing: อยู่ระหว่างจัดคิวหรือส่งต่อ
- ✓Delivered: ได้รับสถานะว่าส่งถึงปลายทาง
- ✓Failed/Rejected: ส่งต่อไม่ได้หรือข้อมูลไม่ผ่านเงื่อนไข
- ✓Expired/Unknown: ไม่มีผลลัพธ์ภายในช่วงเวลาที่กำหนด
เก็บข้อมูลที่ช่วยตามหาปัญหา
แต่ละข้อความควรเชื่อมโยง Business Event กับ Message ID โดยไม่เก็บเนื้อหาหรือข้อมูลส่วนบุคคลเกินความจำเป็น
- ✓Message ID และ Idempotency Key
- ✓ประเภทเหตุการณ์ เช่น order.shipped
- ✓เวลารับคำขอ เวลาส่งต่อ และเวลาได้สถานะ
- ✓Provider/Operator response code ที่แปลงเป็นสถานะกลาง
- ✓จำนวนครั้งที่ Retry และสาเหตุครั้งล่าสุด
ออกแบบ Webhook และ Retry อย่างปลอดภัย
Webhook อาจถูกส่งซ้ำหรือมาถึงไม่เรียงลำดับ ระบบปลายทางจึงต้องตรวจลายเซ็น ตรวจ Message ID และประมวลผลแบบ Idempotent ส่วนการ Retry ควรใช้ Backoff และทำเฉพาะความผิดพลาดที่มีโอกาสหายได้
สร้าง Dashboard ที่ทีมธุรกิจอ่านได้
Developer ต้องเห็น Error Code ส่วนทีมบริการลูกค้าต้องเห็นสถานะที่อธิบายได้ เช่น รอส่ง ส่งแล้ว หรือควรตรวจหมายเลข การมีสถานะกลางชุดเดียวช่วยลดการตีความต่างกันระหว่างทีม
SMS API
วาง Trigger, Message Flow และ Delivery Status ให้ทีมธุรกิจและ Developer ใช้ข้อมูลชุดเดียวกัน