API Rate Limit Calculator: คำนวณ Rate ที่ปลอดภัยจาก Quota ของ API

API ทุกตัวที่เรา integrate ด้วยมาพร้อมตัวเลขหนึ่ง: 6,000 requests ต่อนาที, 100,000 requests ต่อวัน, หรือ 50 requests ต่อวินาที ตัวเลขพวกนี้อ่านง่ายแต่ใช้ยากกว่าที่คิด — worker ของเราจะเรียก endpoint ได้เร็วแค่ไหนโดยไม่โดน 429 Too Many Requests? ควรใส่ delay ระหว่าง call เท่าไหร่? ควรตั้ง burst allowance ไว้ขนาดไหน? API Rate Limit Calculator ตอบคำถามทั้งหมดนี้ในหน้าเดียว — กรอก quota, burst และ window แล้วรับคำตอบกลับมาเป็น safe sustained rate, ค่า delay สำหรับ client-side throttling, การตั้งค่า token bucket และ hint สำหรับ Retry-After

ถ้าเคย ship scraper, backfill job หรือ API client ที่รันใน staging ผ่านฉลุยแต่โดน throttle ใน production เครื่องมือนี้ทำมาเพื่อคุณ เอกสาร rate limit ส่วนใหญ่เขียนจากมุมมองของ server ("เราอนุญาต X ต่อ window") ไม่ใช่มุมมองของ client ("แล้ว code ของฉัน ควรทำอะไร?") การปิดช่องว่างนี้แหละคือหน้าที่ของ calculator ตัวนี้ แถมรัน 100% client-side ใน browser ด้วย นโยบาย API ภายในของทีมคุณจึงไม่เคยออกไปจากเครื่องเลย

ในคู่มือนี้เราจะพาไปดูว่า calculator ทำงานอย่างไร, concept ของ rate limiting ที่อยู่เบื้องหลัง และวิธีเอาผลลัพธ์ไปใช้จริงในระบบ production

ทำไมต้องใช้ API Rate Limit Calculator?

• เลี่ยง HTTP 429 ก่อนที่มันจะเกิด. 429 Too Many Requests ไม่ใช่แค่เรื่องน่ารำคาญ — API gateway หลายตัวลงโทษด้วย penalty box หรือแบนชั่วคราวสำหรับ client ที่เกิน limit ซ้ำ ๆ การวางแผน request rate ตั้งแต่แรกช่วยให้คุณอยู่ในเกณฑ์ดี ๆ ของ provider
• แปลง quota ให้เป็นตัวเลขที่เอาไปเขียนโค้ดได้เลย. Provider ประกาศ quota แบบ "6,000 requests ต่อนาที" แต่ HTTP client ของคุณต้องการ per-request delay, cap แบบ requests-per-second หรือ configuration ของ token bucket — calculator ทำ unit conversion นี้ให้
• อยู่ใต้เพดานด้วย safety margin. หารตรง ๆ (6,000 ÷ 60 = 100 req/s) เท่ากับวิ่งชิดเพดานเป๊ะ ซึ่ง clock drift กับ retry เพียงเล็กน้อยก็ทำให้ทะลุ — safety margin ที่ปรับได้ (10–20%) ให้ headroom ที่สมจริง
• ตั้งค่า burst อย่างตั้งใจ. Burst สั้น ๆ เป็นเรื่องปกติ — cache warm-up, batch fetch, startup fan-out — โมเดล token bucket ของเครื่องมือบอกคุณว่าใช้ burst capacity ได้เท่าไหร่ก่อนเสี่ยง overflow
• วางแผนครอบคลุมทุก time budget. Quota เดียวกันหมายถึงเพดานต่างกันเมื่อมองเป็นรายวินาที รายนาที รายชั่วโมง และรายวัน — calculator โชว์ทั้งสี่แบบพร้อมกันให้เลือกให้เหมาะกับรูปทรง workload
• ก๊อปแผนไปใส่ runbook. Rate-Limit Plan Summary ที่ generate ให้เป็นข้อความพร้อมก๊อป วางลง documentation, บทสนทนาใน code review หรือ post-mortem ได้ทันที

ฟีเจอร์หลัก

มีสองรายละเอียดที่ทำให้เครื่องมือนี้ใช้งานได้จริงในชีวิตประจำวัน อย่างแรกคือทุกอย่างคำนวณใหม่แบบ real-time ตอนพิมพ์ ทำให้เปรียบเทียบ scenario ได้เร็ว ("ถ้า provider ตัด quota เราครึ่งนึงจะเป็นอย่างไร?") อย่างที่สองคือ output ถูกแสดงในหน่วยที่ engineer ใช้ตั้งค่าจริง ๆ: millisecond ของ delay สำหรับ throttled loop, capacity กับ refill rate สำหรับ implement token bucket และค่า Retry-After สำหรับ retry handler

วิธีใช้งาน

1. กรอก total quota. พิมพ์จำนวน request ที่ provider อนุญาต — เช่น 6,000 requests
2. ตั้ง burst capacity. ใส่จำนวน request สูงสุดที่ยอมให้ spike สั้น ๆ เช่น 200 — ค่านี้จะกลายเป็นขนาด token bucket
3. ตั้ง window เป็นวินาที. ใส่ความยาวของ rate-limit window — 60 สำหรับ limit รายนาที, 3,600 รายชั่วโมง, 86,400 รายวัน
4. ปรับ safety margin. เลือกเปอร์เซ็นต์ที่จะหักออกจาก raw rate — 15% เป็นค่า default ที่สมเหตุสมผล ส่วน provider ที่เข้มงวดก็ใช้ margin สูงขึ้น
5. อ่านผลลัพธ์แล้วก๊อปแผน. คุณจะเห็น safe steady-state rate (รายวินาที นาที ชั่วโมง วัน), delay ระหว่าง request, token bucket capacity กับ refill rate และ hint ของ Retry-After — ก๊อป Rate-Limit Plan Summary ไปใส่ docs ได้เลย

จากตัวอย่างที่ใช้ตลอดคู่มือ — quota 6,000 requests ต่อ window 60 วินาที, burst 200, margin 15% — calculator รายงานประมาณ 85 req/s แบบ sustained และ delay ระหว่าง request ประมาณ 11.8 ms

เข้าใจ Concept ของ Rate Limiting

Quota, window และ steady-state rate. Quota คือจำนวน request ที่อนุญาตภายใน window หนึ่ง ๆ ส่วน steady-state rate ก็คือ quota ÷ window ง่าย ๆ แต่ตัวเลขนั้นเป็น ทฤษฎีสูงสุด ไม่ใช่เป้าหมาย — การวิ่งที่ค่าสูงสุดเป๊ะ ๆ แปลว่า concurrency, retry หรือ clock skew เพียงนิดเดียวก็พอทำให้ทะลุเพดาน safe rate คือค่าที่หัก margin ออก: 6,000 ÷ 60 × 0.85 ≈ 85 req/s

ทำไม safety margin ถึงสำคัญ. ในระบบ distributed, client หลายตัวอาจแชร์ quota เดียวกัน, retry ทำให้ traffic บวมตอนเกิด error และ window ของ gateway แทบไม่เคยตรงกับนาฬิกาของ client เป๊ะ ๆ margin 10–20% ดูดซับสิ่งเหล่านี้ได้หมด ให้มอง margin เป็นประกันราคาถูก: เสีย throughput 15% คุ้มกว่าโดน penalty หรือเกิด incident เสียอีก

Token bucket vs. leaky bucket. Token bucket เก็บ token ได้สูงสุด B ชิ้นและเติม (refill) ในอัตรา R ชิ้นต่อวินาที ทุก request กิน token หนึ่งชิ้น ถ้า bucket ว่างก็ต้องรอ — โมเดลนี้อนุญาต burst แบบควบคุมได้ (สูงสุด B request ติดกัน) โดยยังล็อกค่าเฉลี่ยระยะยาวไว้ที่ R ส่วน leaky bucket เรียง traffic ให้ออกแบบสม่ำเสมอคงที่แทน แลก burst tolerance กับ pacing ที่สม่ำเสมอเป๊ะ API gateway สมัยใหม่ส่วนใหญ่ (และ library อย่าง golang.org/x/time/rate หรือ RateLimiter ของ Guava) implement ตระกูล token bucket นี่คือเหตุผลที่ calculator รายงาน capacity และ refill rate เป็น output หลัก

Client-side throttling delay. Throttle ที่เรียบง่ายที่สุดคือ sleep คงที่ระหว่าง request: delay = 1,000 ms ÷ safe RPS — ที่ 85 req/s ก็ได้ประมาณ 11.8 ms วิธีนี้ implement ง่ายและคิดง่าย แต่ระบบ production มักนิยม rate limiter ที่เหมาะสมที่รองรับ concurrency ด้วย

HTTP 429 และ Retry-After. เมื่อเกิน limit จริง ๆ server ที่ดีจะตอบ 429 Too Many Requests พร้อม header Retry-After (หน่วยวินาที) — client ของคุณควรเคารพค่านี้ เพราะมันสะท้อนตาราง recovery จริงของ server ไม่ใช่การเดา ถ้าไม่มี header ประมาณการจาก calculator ก็เป็น fallback ที่สมเหตุสมผลจาก quota และ window ของคุณ

Use Cases ในทางปฏิบัติ

ทำ web scraper แบบสุภาพ

Scraper ที่รัวเครื่องเป้าหมายย่อมโดน block ไม่ว่าจะมี rate limit หรือไม่ — กรอก limit ที่เว็บเป้าหมายประกาศ (หรือค่า conservative ที่เดาไว้) เอา safe rate กับ inter-request delay ไปใช้ pace ตัว crawler การผสม throttle delay เข้ากับ Cron Parser สำหรับจัด schedule หน้าต่าง crawl ทำให้ job ใหญ่ ๆ คาดการณ์ได้และสุภาพต่อเว็บเป้าหมาย

ปรับค่า API client SDK

SDK ที่ service หลายตัวใช้ร่วมกันควรมี limiter ในตัวเพื่อไม่ให้ผู้ใช้คนหนึ่งเผา quota ทั้งทีม — เอา quota ของ provider ยัดเข้า calculator แล้วเอา refill rate กับ bucket capacity ที่ได้ไปตั้งค่า limiter ใน SDK วิธีนี้เปลี่ยนนโยบายกำปั้นตีปลาย ("ใจดี ๆ กับ API หน่อย") ให้เป็นตัวเลขที่ enforce ได้จริง

งาน migration และ backfill

Backfill เป็นงาน heavy burst โดยธรรมชาติ: ข้อมูลหลายล้านแถว เดดไลน์กระชับ — output แบบ token bucket บอกคุณว่า pace ที่ sustainable เร็วสุดคือเท่าไหร่และ front-load ตอน startup ได้เท่าไหร่ เอาตัวเลขไปรันกับ quota ของ destination API ก่อน งานจะจบโดยไม่ชนกำแพง throttling กลางทาง

เชื่อมต่อ third-party API ที่มี gateway limit

API gateway ภายในองค์กรมัก apply limit แบบ per-client, per-route และแบบ global พร้อมกัน — คำนวณ safe rate จากตัวที่คับที่สุดแล้วถือเป็นเพดานของ client ของคุณ ตอน debug ว่าทำไม request ถูกปฏิเสธ HTTP Status Code Lookup ช่วยยืนยันว่า 429 (หรือ variant เฉพาะของ gateway) หมายถึงอะไร ส่วน JWT Decoder ใช้ตรวจ token ที่ client ส่งไป — มีประโยชน์เมื่อ quota tier ผูกอยู่กับ claims ใน token

Best Practices

• เคารพ Retry-After เมื่อ server ให้มา. server รู้ตาราง recovery ของตัวเองดีที่สุด — override ด้วย retry ที่รุนแรงแค่ทำให้ throttling แย่ลง
• ใช้ exponential backoff with jitter. ถ้าไม่มี header Retry-After ให้เพิ่ม delay เป็นเท่าตัวหลังแต่ละ 429 แล้วสุ่ม jitter เข้าไป เพื่อไม่ให้ client หลายตัว retry พร้อมกันเป็นจังหวะเดียว
• รักษา safety margin ไว้ที่ 10–20%. เป็นวิธีป้องกันที่ถูกที่สุดจาก clock skew, retry และการแชร์ quota หลาย client
• เฝ้า monitor อัตรา 429. ตัวเลขเล็ก ๆ คงที่แปลว่าคุณใกล้ขอบ — spike กระทันหันมักแปลว่า upstream มี incident หรือเกิด retry storm
• กำหนด burst อย่างมีเป้าหมาย. ตั้ง burst capacity ตามที่จำเป็นจริง (cache warm-up, fan-out) ไม่ใช่ตามที่ bucket รับไหวสูงสุด
• จดบันทึกแผน. วาง Rate-Limit Plan Summary ลงใน README ของ service เพื่อ engineer คนถัดไปไม่ต้องคำนวณตัวเลขใหม่จากศูนย์

เริ่มวางแผน Request Rate ของคุณวันนี้

Rate limit จะเลิกเป็นสิ่งที่คาดไม่ถึงในวันที่คุณแปลงมันเป็นตัวเลข concrete ฝั่ง client — สละเวลาสองนาทีกับ API Rate Limit Calculator: กรอก quota ของ provider, ตั้ง margin ที่สมเหตุสมผล แล้วรับกลับไปเป็น safe request rate, throttle delay, การตั้งค่า token bucket และ retry hint ที่วางลง code กับ runbook ได้เลย ไม่ต้องสมัครสมาชิก ไม่มีการเก็บข้อมูล — มีแต่คณิตศาสตร์ที่คำนวณให้เสร็จ

ขอให้สนุกกับการ build!