Rate Limiter

API rate limiting is the practice of restricting how frequently clients can make API requests. Rather than allowing unlimited requests, servers limit requests to some maximum rate: 100 requests per minute, 10,000 per hour, or similar. When clients exceed limits, servers reject additional requests, returning rate limit exceeded responses.

Security Benefits: Rate limiting prevents abuse. Attackers attempting credential stuffing attacks (trying thousands of username-password combinations) are severely hampered—even at one request per second, trying 1 million credentials takes 278 hours. Rate limiting reduces this from feasible to prohibitive. Similarly, brute force attacks trying dictionary passwords are slowed dramatically. API scraping attempts (mass data collection) become expensive and time-consuming. Denial-of-service attacks require far more resources when rate limiting forces attackers to use many sources.

Stability Benefits: APIs are resources shared among many clients. Uncontrolled usage by single clients can monopolize resources, degrading performance for others. A bug causing client software to send requests in tight loops could crash servers. Rate limiting ensures fair resource allocation. Additionally, rate limiting forces developers to think about efficiency—clients hitting rate limits must optimize their API usage, reducing overall system load.

Business Benefits: For commercial APIs, rate limiting is monetization—tier users by request limits (free tier: 100/day, pro tier: 100,000/day) charging accordingly. This creates revenue model. Additionally, rate limiting prevents accidental abuse where legitimate applications are poorly written and send excessive requests.

Token Bucket Algorithm: Clients start with a bucket of tokens (capacity). Each request consumes tokens. Tokens refill at fixed rate (e.g., 100 tokens per minute). If bucket is empty, requests are rejected. Advantages: allows bursty traffic (many requests at once if bucket is full), smooth traffic spreading, and easy to implement. Disadvantages: bursty traffic can spike usage beyond average rate, requiring careful capacity tuning.

Sliding Window Log Algorithm: Tracks timestamps of recent requests. For each new request, count how many requests occurred in the last time window (last minute). If count exceeds limit, reject. Advantages: accurate rate limiting without allowing bursts. Disadvantages: high memory usage (storing all request timestamps), and higher computation (counting requests for each check).

Sliding Window Counter Algorithm: Hybrid approach combining token bucket and sliding window. Divides time into fixed intervals (seconds), counting requests in current interval and weighted portion of previous interval. More memory-efficient than sliding window logs, prevents excessive bursts while allowing some burstiness. This is commonly used in production systems.

Leaky Bucket Algorithm: Requests flow into a bucket with fixed capacity. Requests leave bucket at fixed rate (processing). When bucket is full, additional requests are dropped. Useful for smoothing traffic but less flexible than token bucket—can't handle legitimate traffic spikes.

Algorithm Selection: Choose based on use case. Token bucket is simplest for general API rate limiting. Sliding window counters are better for strict rate limiting where bursts must be prevented. For critical resources, combine approaches—token bucket for general limiting plus sliding window for emergency braking on extreme overuse. Additionally, different endpoints might use different algorithms—read-only endpoints might have higher limits than write operations.

Per-Client Identification: Rate limiting must identify clients consistently to prevent trivial circumvention. Common approaches: (1) API keys—unique identifier per client, (2) User IDs for authenticated users, (3) IP addresses for unauthenticated requests. IP addresses are problematic because many clients share IPs (corporate networks, mobile carriers), so legitimate users behind shared IPs quickly exhaust limits. For public APIs, use API keys (requiring registration) or combine IP-based limiting with user-based limiting to avoid penalizing legitimate users.

Limit Configuration: Set limits based on expected legitimate usage plus reasonable margin. Too-strict limits frustrate legitimate users; too-loose limits fail to prevent abuse. Analyze legitimate traffic patterns—average requests per user per minute, peak traffic, any temporal patterns. Set limits 2-3x above peak legitimate usage, allowing headroom for temporary spikes. Different endpoint types warrant different limits—bulk data export endpoints might allow 10 requests/minute, while search endpoints allow 100/minute.

Graduated Penalties: Rather than immediate blocking, implement graduated responses: first limit exceeded shows warning, continue exceeding triggers rate limiting (slower responses), sustained abuse triggers IP blocking. This allows legitimate users to adjust without losing service, while still protecting against attacks.

Common Mistakes: Not identifying per-user for authenticated APIs (identifying by IP blocks all users from shared networks). Setting limits too strict (legitimate use triggers limits). Not accounting for retry behavior (when clients retry failed requests, this consumes additional quota). Not implementing rate limit headers (clients don't know current status until they hit limits). Not differentiating by endpoint (all endpoints share quota, causing one expensive endpoint to exhaust quota for others).

Rate Limit Headers: Inform clients of current rate limit status through HTTP headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. These headers let clients optimize behavior—backing off when approaching limits rather than discovering limits through rejection. Standard headers enable client libraries to implement automatic backoff and retry strategies.

Centralized State Challenges: Distributed systems have multiple servers handling requests. Rate limit state (current request count) must be shared across servers—can't track separately per server or distributed clients can exceed limits by distributing requests across servers. This requires centralized state storage.

Redis-Based Implementation: Redis is the common choice for distributed rate limiting. Redis is fast (microsecond latency), supports atomic operations (incrementing counters atomically), and enables expiring keys automatically. For each client (identified by API key or user ID), maintain a counter in Redis incremented on each request. Use Redis TTL (time-to-live) to automatically reset counters—key expires after rate-limit window passes, removing manual cleanup.

Example Flow: Client makes request with API key. Server queries Redis for request_count:api_key. If count exceeds limit, reject. Otherwise, increment counter and set TTL to 60 seconds (for per-minute limits). Next request within 60 seconds increments counter. After 60 seconds, counter expires and resets. This scales to millions of clients with microsecond latency.

Distributed Consistency: Redis replication ensures data survives server failures, but introduces complexity—replication has slight latency, potentially allowing brief overages. For critical systems, use Redis clusters with strong consistency guarantees. For systems tolerating minor overages, standard Redis replication is sufficient.

Edge Cases and Failover: If rate limiting service is unavailable, decide: fail open (allow all requests) or fail closed (deny all requests). Fail open compromises security but maintains availability. Fail closed maintains security but impacts user experience. Most systems implement hybrid—local per-server rate limiting as fallback if central service is unavailable. This prevents abuse if service fails but allows some traffic through.

Rate Limiting for Brute Force and Credential Stuffing: Rate limiting is a key defense against authentication attacks. Combined with account lockouts and MFA, it makes credential stuffing attacks expensive and time-consuming. A 5-request-per-minute limit on login endpoints forces attackers to use distributed sources. Combined with MFA (defeating even correctly guessed credentials), this makes password attacks impractical.

DDoS Mitigation: Rate limiting is a first layer against DDoS attacks, but not sufficient alone. Volumetric attacks exceeding network capacity can overwhelm servers before rate limiting is effective. Combine rate limiting with network-layer DDoS mitigation (bandwidth filtering, anycast distribution). Application-layer DDoS often requires rate limiting plus WAF rules and geographic filtering.

API Quotas and Authorization: Different from rate limiting (time-based), quota systems limit total usage (10,000 API calls per month). Authorization controls what data users can access. Rate limiting controls how frequently they can access it. All three together provide comprehensive API security: authorization determines what's accessible, rate limiting controls frequency, quotas control total usage.

Monitoring and Anomaly Detection: Rate limiting generates events—when clients hit limits, these can indicate attack attempts or legitimate problems. Monitor rate limit triggering patterns: sudden spikes suggest attacks, gradual growth suggests legitimate traffic increase. Combine with behavioral analysis—if rate limiting triggers on unusual endpoints or times, alert security teams.

User Experience Considerations: Aggressive rate limiting impairs user experience. Legitimate applications sometimes make bulk requests—data imports, dashboard initialization, report generation. Overly tight limits frustrate legitimate users. Graduated response (warnings before blocking), clear communication (rate limit headers), and user bypass mechanisms (dedicated high-volume access paths) balance security with usability.