🔴 Redis Architecture
API Rate Limiting (Token Bucket & Sliding Window)
Protecting APIs from abuse with Redis Token Bucket and Sliding Window
Without rate limiting, a single malicious user (or buggy script) can send thousands of requests per second, taking down your entire database. Rate limiting sits at the API Gateway, tracking request counts in Redis, and rejecting excess requests (HTTP 429) before they reach your fragile backend.
Key Concepts
API Gateway Layer
Rate limiters must be deployed at the edge (Gateway) or as middleware. If the request reaches your database, the rate limiter has already failed its primary job of protecting infrastructure.
Why Redis?
Rate limiting requires extreme speed. Checking a limit must take <1ms. Redis stores data in RAM and its single-threaded nature guarantees atomic increments (no race conditions).
Fixed Window Strategy
The simplest algorithm. You increment a counter for a specific time window (e.g., `rate:ip:192.168.1.1:14:05`). Pros: Memory efficient. Cons: Spike at the window boundary can allow double the limit.
Token Bucket Strategy
A bucket holds N tokens. Every request costs 1 token. The bucket refills at a constant rate. Pros: Allows sudden bursts, but maintains a steady long-term rate.
Rate Limiting Architecture
Comparing Rate Limiting Algorithms
| Algorithm | Pros | Cons |
|---|---|---|
| Fixed Window | Simplest to implement (just INCR), low memory. | Boundary problem: bursts of traffic can occur exactly at the minute mark. |
| Sliding Window Log | Perfect accuracy. Tracks timestamp of every request. | High memory usage (stores timestamps in Sorted Sets). |
| Sliding Window Counter | Balances memory and accuracy. | Slightly complex math (weighted average of previous and current window). |
| Token Bucket | Allows smooth bursts of traffic. | Requires background job or complex timestamp math to 'refill' tokens. |
💡
Senior Architect Insight: In a distributed system, a Rate Limiter MUST be centralized. If you have 10 API Gateway instances and you do rate limiting in-memory on each instance, a limit of '100 requests/min' actually becomes '1000 requests/min' across the cluster. Redis ensures all 10 instances share the same state.