Design a Distributed Rate Limiter
A rate limiter acts as a digital bouncer at the door of your API, ensuring each client stays within their allowed request limits (e.g. 100 requests per minute) and blocking abusive traffic.
Live Architecture Studio
Edit components, modify labels, add databases, or redraw connections directly on this canvas:
Loading API Rate Limiter Blueprint...
Mounting vector diagram elements, nodes, and capacity metrics
Loading API Rate Limiter Blueprint...
Mounting vector diagram elements, nodes, and capacity metrics
1. Problem & Challenge
Malicious bots or buggy third-party scripts can spam your server with 10,000 requests in 1 second. Without a rate limiter, this knocks down databases and crashes service for paying users.
2. Core Building Blocks & Responsibilities
👉 Desliza la tabla para ver roles y responsabilidades| Component | Role | Plain-English Explanation |
|---|---|---|
| API Gateway Middleware | The Bouncer | Intercepts incoming HTTP headers (API Key or IP address) before the request ever reaches real backend servers. |
| Redis In-Memory Counter | High-Speed Ledger | Tracks how many tokens or requests each user has made in the last 60 seconds with sub-millisecond lookups. |
| Token Bucket Algorithm | Algorithm Rule | Adds fresh tokens into a virtual bucket at a steady rate. Each API call consumes 1 token. When the bucket is empty, requests are rejected. |
| HTTP 429 Error Responder | Feedback Mechanism | Returns HTTP 429 Too Many Requests along with a Retry-After header telling the client when they can retry. |
3. Step-by-Step Request Flow
Request Hits API Gateway
Incoming HTTP request is tagged with the user ID or client IP address.
Atomic Redis Lookup
A Lua script in Redis checks the remaining tokens and decrements by 1 atomically (preventing race conditions).
Decision Point
If tokens >= 0, the request is forwarded to backend microservices. If tokens < 0, it is immediately dropped with HTTP 429.
4. Architectural Trade-offs
Client-side vs Server-side Limiting
Chosen: Server-side API Gateway
Rationale: Client-side limits can be easily bypassed by attackers tampering with requests.
Centralized Redis vs Local Server Memory
Chosen: Centralized Redis with Local Cache Fallback
Rationale: Centralized Redis handles multi-server clusters accurately so clients cannot bypass limits by round-robining servers.
Interview Tip
Always explain the race condition problem: two simultaneous requests from the same user hitting different servers at the exact same millisecond. Mention Redis Lua scripts as the clean solution.
Explore Related System Blueprints
TinyURL Shortener
A URL shortener converts a long link (like a 100-character article URL) into a compact 7-character key (like tinyurl.com/xyz123) and redirects visitors in under 15 milliseconds.
Video Streaming CDN
Streaming high-definition video to millions of smart TVs and mobile phones requires breaking large 10GB video files into tiny 5-second chunks, encoding each into 20 different resolutions, and caching them right inside local ISP networks.
Uber Dispatch Engine
A real-time geospatial dispatch system matches riders with the most optimal nearby drivers using 64-bit H3 hexagonal indexing and 2-second batch optimization, minimizing city-wide pickup ETA and driver idle time.
Stripe Payments Ledger
A resilient financial payments architecture guarantees strict consistency (CP system) using cryptographic idempotency reservation, double-entry balanced postings, and sharded balance locks.
Figma Multiplayer Engine
A real-time multiplayer document engine uses stateful sticky session routing and server-authoritative operational ordering to sync 2D scene graphs across worldwide collaborators without locking.
Twitter Timeline & Feed
A timeline generation system balances high write amplification against fast sub-50ms reads by pushing tweets to followers of regular accounts, while pulling and merging celebrity tweets on-demand.