Rate limiting จำกัดจำนวนคำขอที่ client สามารถส่งได้ภายในช่วงเวลาหนึ่ง — เพื่อปกป้องระบบจากการใช้งานในทางที่ผิด การโอเวอร์โหลด และเพื่อให้แน่ใจว่ามีการใช้งานอย่างเป็นธรรม มันเป็นองค์ประกอบที่พบบ่อยในการออกแบบระบบ โดยมีหลายอัลกอริทึมและข้อพิจารณาให้เลือกใช้
ทำไมต้องมี rate limiting
text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
อัลกอริทึมของ rate limiting
text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)