แยก idempotency ของระบบต้นทางออกจาก HTTP method

1. ระบุจุดที่ผลธุรกิจกับเครือข่ายแยกจากกัน

การใช้ POST ไม่ได้บอกทั้งหมดว่าปลายทางกันเหตุการณ์ซ้ำอย่างไร และส่ง header ชื่อเหมือน idempotency ก็ไม่ทำงานถ้า API ไม่รองรับ

RFC 9110 นิยามความหมายของ HTTP แต่ผลธุรกิจยังต้องอ่านจาก body ตามสัญญา MeeTang อย่าตัดสินจากสถานะการเชื่อมต่ออย่างเดียว

2. ขั้นตอนที่ต้องออกแบบในระบบร้าน

กำหนดผู้รับผิดชอบและเก็บหลักฐานให้ตามเหตุการณ์เดียวกันได้ก่อนเปิดใช้งานจริง ขั้นตอนเหล่านี้ไม่ใช่ฟีเจอร์ที่เปิดให้เองเมื่อสร้าง key

• ตรวจพฤติกรรม retry ของ endpoint ที่ใช้จริง
• เก็บ event ID ฝั่งต้นทางหนึ่งค่าต่อเหตุการณ์
• ทำ test ส่งเหตุการณ์เดิมซ้ำและตรวจจำนวนรายการกับยอด ไม่ตรวจแค่ HTTP

3. กรณีจำลองสำหรับตรวจผล

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

4. ข้อจำกัดและกรณีที่ต้องหยุด

การตรวจซ้ำภายนอกเป็น application-level ไม่ใช่ atomic guarantee ที่ประกาศไว้ ต้อง serialize เหตุการณ์เดียวกัน; Payment X-Request-Id ใช้ติดตาม ไม่ใช่กันเติมซ้ำ

5. เชื่อมหลักฐานกับ MeeTang

เทียบ API Docs กับ Payment Docs แล้วตรวจผลรายการใน API Logs ก่อนเปิด retry อัตโนมัติ

รายละเอียดผลิตภัณฑ์ตรวจจาก source และไฟล์สัญญาใน repository วันที่ 27 กันยายน 2026 ไม่ใช่การยืนยันว่า deployment ทุกตัวมีพฤติกรรมตรงกันแล้ว

แหล่งอ้างอิงและขอบเขตเนื้อหา

แหล่งต่อไปนี้อธิบายหลักการทั่วไป ส่วนขั้นตอนของ MeeTang ตรวจจากฟีเจอร์ในระบบ ณ วันที่อัปเดต ตัวเลขในตัวอย่างไม่ใช่ข้อมูลผู้ใช้งานจริง

• RFC 9110: HTTP Semantics — ความหมาย HTTP method, status, representation และ idempotency

จัดทำด้วย AI ช่วยเรียบเรียงและตรวจเทียบกับโค้ด ไม่ใช่คำแนะนำภาษีหรือการรับรองผลทางบัญชี เงื่อนไขฟีเจอร์และโควตาขึ้นกับแพ็กเกจและสิทธิ์ที่ได้รับ