ออกแบบ retry, idempotency และ rollback
ทำให้ระบบรับมือ timeout และบริการล่มโดยไม่ส่งข้อความซ้ำ ตัดเงินซ้ำ หรือสร้างรายการซ้ำ
เป้าหมาย: จำแนกข้อผิดพลาดชั่วคราวกับถาวร และกำหนด retry policy, idempotency key, dead-letter queue และ rollback · ใช้เวลาประมาณ 17 นาที
กรอบออกแบบก่อนเปิดใช้งาน
กำหนดขอบเขตและหลักฐานให้ชัดก่อนเชื่อม AI เข้ากับงานจริง
จำแนก error
แยก timeout rate limit 5xx จาก validation permission และข้อมูลไม่ครบ
Retry อย่างจำกัด
ใช้ exponential backoff, jitter, max attempts และ deadline
กันผลซ้ำ
ผูก idempotency key กับเหตุการณ์และการกระทำ ไม่ใช่แต่ละรอบเรียก
กู้คืน
มี dead-letter queue การแจ้งเตือน วิธี replay และ rollback ที่ทดสอบแล้ว
กรณีงานธุรกิจไทย
ส่งข้อความ LINE OA
ใช้ message job id เดิมทุก retry และเช็ก sent state ก่อนส่ง
timeout หลังส่งไม่ทำให้ลูกค้าได้รับข้อความซ้ำ
บันทึกคำสั่งซื้อ
upsert ด้วย order id จากต้นทางแทน insert ทุก event
เหตุการณ์ซ้ำไม่สร้างรายการใหม่
จุดล้มเหลวและวิธีป้องกัน
retry ทุก error
permission ผิดถูกยิงซ้ำและเพิ่มต้นทุน
หยุดทันทีเมื่อ error ถาวร
สร้าง key ใหม่ทุกครั้ง
ระบบมองเป็นการกระทำใหม่
derive key จาก business event
ไม่มี rollback
ข้อมูลครึ่งหนึ่งสำเร็จและแก้ยาก
ออกแบบ compensating action และซ้อม
ป้องกันคูปองซ้ำ
workflow สร้างคูปองหลังอนุมัติ แต่ API timeout หลังคำขอ ผู้ใช้กดซ้ำ และ queue retry
ออกแบบสถานะและ idempotency
ดูคำตอบตัวอย่าง
สร้าง redemptionRequestId หนึ่งค่า ตรวจ approved state ใช้ idempotency key เดิมกับ API ทุก attempt บันทึก pending/succeeded/failed_unknown จำกัด retry; หากไม่ทราบผลให้ query ก่อนสร้างใหม่ และส่ง failed_unknown ให้พนักงาน ห้ามออกคูปองชดเชยเอง
- key ระดับธุรกิจ
- retry จำกัด
- query ก่อนทำซ้ำ
- มี unknown state
- rollback/escalation
บันทึกช่วยจำ
- การกระทำที่ย้อนกลับไม่ได้ควรต้องมีการอนุมัติและการยืนยันซ้ำจากระบบ
- ทดสอบ timeout ทั้งก่อนและหลังปลายทางทำสำเร็จ
สรุปบทเรียนนี้
- retry ไม่ใช่คำตอบของทุก error
- idempotency ป้องกันผลซ้ำ
- unknown ต้องตรวจและส่งต่อ ไม่เดา