Rate​ ​Limit​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ ​API​ ​จึง​ต้อง​จำกัด​จำนวน​ ​Request

Rate Limit คือการจำกัดจำนวนหรือความถี่ของ Request ที่ Client ส่งถึง API ภายในขอบเขตหนึ่ง เช่น ต่อบัญชี ต่อ Token หรือต่อช่วงเวลา ใช้ป้องกันทรัพยากรถูกใช้เกินและจัดความเป็นธรรมระหว่างผู้ใช้ แต่แต่ละผู้ให้บริการกำหนดขอบเขตและวิธีนับต่างกัน ต้องอ่านเอกสารจริง

เมื่อ Client เรียกเกิน

API อาจตอบ 429 Too Many Requests พร้อมรายละเอียดและ Retry-After เพื่อบอกเวลารอ Client ควรหยุดหรือชะลอ ไม่ส่งซ้ำทันทีอย่างไม่มีขอบเขต เพราะจะเพิ่มภาระและอาจถูกจำกัดต่อ การลองใหม่ต้องคำนึงด้วยว่าคำขอนั้นปลอดภัยต่อการทำซ้ำหรือไม่

ภาพที่ 1: Rate Limit ช่วยคุมโหลด ส่วน Client ต้องรู้วิธีรอและรักษางานที่ยังไม่เสร็จ

ตัวอย่างสมมติ: ซิงก์คำสั่งซื้อ

ระบบหลังบ้านมีออเดอร์ 1,000 รายการต้องส่งไปผู้ให้บริการภายนอก หากยิงพร้อมกันทั้งหมดอาจชน Limit และบางรายการล้มเหลว ควรใช้คิวที่ควบคุมอัตรา บันทึกสถานะต่อรายการ และลองใหม่ตามคำแนะนำของ API พร้อมรหัสกันซ้ำ การลดจำนวน Request ด้วยการส่งแบบ Batch อาจช่วยได้หากผู้ให้บริการรองรับ แต่ต้องตรวจสัญญาและผลของรายการย่อย

Rate Limit ฝั่งผู้ให้บริการกับฝั่งเรา

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

สำหรับรายงาน

ระบุขอบเขตและช่วงเวลาของ Limit ที่อ้างจากผู้ให้บริการ วาดพฤติกรรม Client เมื่อได้ 429 รวมทั้งการเก็บงานที่ยังไม่สำเร็จ หาก Limit ยังไม่ทราบ ให้เขียนเป็นข้อจำกัดของการออกแบบ ไม่สร้างตัวเลขสมมติแล้วเสนอเป็นข้อเท็จจริง

อ่าน API Error Handling และ API Integration Preparation หรือดู บริการระบบหลังบ้านและ API

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ กราฟจำนวนคำขอต่อช่วงเวลาและตัวอย่าง 429 กับ Retry-After ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• RFC 6585: 429 Too Many Requests — นิยามรหัส 429
• Google Cloud: Retry strategy — วิธีเว้นระยะและจำกัดการลองใหม่