Rate Limiting

Rate limiting prevents abuse, ensures fair resource usage, and protects against attacks.

Common strategies

• Fixed window: X requests per Y time period (simple but has burst issues).
• Sliding window: Rolling time window (more accurate).
• Token bucket: Accumulate tokens, spend on requests (allows bursts).
• Leaky bucket: Fixed rate processing (smooths traffic).

Where applied

• APIs: Prevent excessive calls (e.g., 1000/hour).
• Login forms: Prevent brute force (e.g., 5/minute).
• Public endpoints: Protect against DDoS.
• Email sending: Prevent spam (e.g., 100/day).

Implementation

• Store counters in Redis/Memcached.
• Return 429 (Too Many Requests) status.
• Include Retry-After header.
• Provide rate limit headers (X-RateLimit-*).

User experience

• Communicate limits clearly in documentation.
• Provide feedback when limits are approached.
• Offer higher tiers for legitimate high-volume users.