API Rate Limiting Strategies That Actually Work

Rate limiting is one of those things that seems simple until you try to do it well. A naive implementation will either let abuse through or block legitimate traffic. Here is how to build rate limiting that actually works in production.

The Three Layers

Effective rate limiting operates at three distinct layers:

1. Global limits protect your infrastructure from total overload. These are high thresholds that should rarely be hit by any single consumer.
2. Per-consumer limits (by API key or IP) prevent individual users from monopolizing resources. These are the limits you expose in your pricing tiers.
3. Per-endpoint limits protect expensive operations. Your search endpoint might handle 100 req/min while your simple status check handles 1000 req/min.

Sliding Window vs Fixed Window

Fixed window counters are simple but create burst problems at window boundaries. A user could send 100 requests at 11:59 and another 100 at 12:00, effectively doubling their rate.

Sliding window algorithms solve this by tracking requests across a rolling time period. The sliding window log approach is the most accurate but requires more memory. The sliding window counter is a good compromise — it interpolates between the current and previous windows to approximate a true sliding window with minimal overhead.

Communicating Limits to Clients

Always include rate limit headers in your responses:

• X-RateLimit-Limit: Maximum requests allowed
• X-RateLimit-Remaining: Requests left in current window
• X-RateLimit-Reset: Unix timestamp when the window resets
• Retry-After: Seconds to wait before retrying (on 429 responses)

Good documentation and clear error messages turn rate limiting from a frustration into a feature. When developers understand and can predict your limits, they build better integrations.