Rate limiting enforces a maximum request rate for a given identity — usually an IP address or authenticated session. It's a fundamental DDoS mitigation tool. It's also the source of countless false positives that block real users, frustrate customers, and trigger support escalations. The key is choosing the right granularity.
Dimensions to Rate Limit On
- Per IP address: simplest, but fails against distributed attacks from large botnets (one request per IP).
- Per IP + User-Agent: adds a dimension, still spoofable.
- Per session token: accurate for authenticated endpoints, irrelevant for public pages.
- Per ASN: broad strokes for geographic blocking — useful for attacks concentrated in one network.
- Per endpoint: different limits for /search vs /login vs /checkout based on computational cost.
The Threshold Problem
Setting thresholds is where most implementations fail. Too low: mobile users on shared carrier NAT (many users behind one IP) get blocked. Too high: bots at 99 requests per minute (just under your 100 limit) aren't stopped. The solution is dynamic thresholds based on observed normal behavior — exactly how Akarguard's ML-based rate limiting works.
Best practice
Use a two-tier approach: a hard block at extreme rates (>1,000 req/min/IP) and a soft challenge (CAPTCHA/JS) at moderate rates (>50 req/min/IP). Only block — never challenge — at the extreme tier.
Endpoint-Specific Rules
A product listing page can absorb 500 requests/minute without issue. A password reset form should trigger alerts at 5 requests/minute per IP. Configure rate limits based on what each endpoint does — not a one-size global rule.