Rate Limiting Basics Every Developer Should Know

What is Rate Limiting?

Rate limiting controls how many requests a client can make to an API or service within a given time window. It prevents abuse, ensures fair usage, and protects backend resources from being overwhelmed. Think of it as a bouncer at a club: only a certain number of people get in per minute.

Why You Need It

Without rate limiting, a single misbehaving client can degrade performance for everyone. Common scenarios:

• A buggy client sends thousands of requests per second.
• A malicious actor tries to brute-force endpoints.
• A scraper hammers your server for data.

Rate limiting mitigates these issues and helps maintain service stability.

Common Algorithms

Token Bucket

A bucket holds tokens, each token allows one request. Tokens are added at a fixed rate (e.g., 10 per second). If the bucket is empty, requests are rejected. This allows bursts up to the bucket size.

import time

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate
        self.capacity = capacity
        self.tokens = capacity
        self.last_refill = time.monotonic()

    def allow(self):
        now = time.monotonic()
        elapsed = now - self.last_refill
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last_refill = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Enter fullscreen mode Exit fullscreen mode

Leaky Bucket

Requests fill a bucket that leaks at a constant rate. If the bucket overflows, requests are throttled. This smooths out bursts and enforces a steady outflow.

Fixed Window

Count requests in a fixed time window (e.g., 100 requests per minute). Simple but can allow bursts at window boundaries.

Sliding Window Log

Track timestamps of requests. Count requests within the last N seconds. More accurate than fixed window but more memory intensive.

Practical Implementation with Redis

Redis is a popular choice for distributed rate limiting. Use INCR and EXPIRE for a simple fixed window:

import redis
import time

r = redis.Redis()

def is_rate_limited(client_id, limit=100, window=60):
    key = f"rate_limit:{client_id}:{int(time.time() // window)}"
    count = r.incr(key)
    if count == 1:
        r.expire(key, window)
    return count > limit

Enter fullscreen mode Exit fullscreen mode

For sliding window, use sorted sets to track timestamps.

HTTP Headers

Communicate limits to clients via standard headers:

• X-RateLimit-Limit: maximum requests per window
• X-RateLimit-Remaining: remaining requests in current window
• X-RateLimit-Reset: time when the window resets (Unix timestamp)

Example response:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1620000000

Enter fullscreen mode Exit fullscreen mode

When exceeded, return 429 Too Many Requests with a Retry-After header.

Handling on the Client Side

As a client, respect rate limits:

• Parse rate limit headers.
• Implement exponential backoff.
• Cache responses when possible.
• Queue requests if you anticipate hitting limits.

Common Pitfalls

• Using IP alone: Behind NAT, many users share an IP. Consider user-based limits (API keys).
• Not accounting for distributed systems: Use a centralized store like Redis.
• Too strict or too loose: Monitor usage patterns and adjust limits.
• Ignoring edge cases: What happens when the clock resets? Use monotonic time if possible.

Conclusion

Rate limiting is a fundamental tool for building resilient APIs. Choose an algorithm that fits your traffic patterns, implement with care, and always communicate limits to your users. Start simple with a fixed window and evolve as needed.