What is Rate Limiting?
Learn what rate limiting is, token bucket vs leaky bucket vs sliding window, and why it protects APIs from overload and abuse.
Expected Interview Answer
Rate limiting is the practice of capping how many requests a client can make to a service within a given time window, protecting the system from overload and abuse while keeping it fair for all clients.
A rate limiter tracks request counts per key — often per user, API key or IP address — and rejects or delays requests once the client exceeds the configured threshold, typically returning an HTTP 429 Too Many Requests response. Common algorithms include the token bucket (tokens refill at a steady rate and each request consumes one), leaky bucket (requests are processed at a fixed steady rate, smoothing bursts), fixed window counters (simple but allow bursts at window edges), and sliding window logs or counters (more accurate but more expensive to track). Rate limiting protects backend resources from being overwhelmed, defends against abuse like brute-force login attempts or scraping, and gives operators predictable capacity planning.
- Protects backend services and databases from being overwhelmed
- Defends against abuse such as brute-force attacks or scraping
- Ensures fair usage across many clients sharing the same service
- Makes capacity planning and cost predictable
AI Mentor Explanation
Rate limiting is like the rule that a bowler can only deliver six balls per over before handing the ball to someone else, no matter how eager they are to keep bowling. Each delivery consumes one of the six allowed slots (tokens), and once they run out, the bowler simply cannot bowl again until the next over refills the count. This keeps any single bowler from dominating and exhausting the game’s pace. That fixed allowance per time window is exactly what rate limiting enforces on a client.
Step-by-Step Explanation
Step 1
Identify the client key
Requests are grouped by user ID, API key, or IP address to track usage per client.
Step 2
Check the current allowance
The limiter checks tokens remaining (or requests counted) in the current window for that key.
Step 3
Allow or reject
If under the limit, the request proceeds and the count is decremented; otherwise it is rejected with HTTP 429.
Step 4
Refill over time
The allowance replenishes on a schedule (token bucket refill, or window reset) so clients regain capacity.
What Interviewer Expects
- Names at least one algorithm: token bucket, leaky bucket, fixed/sliding window
- Mentions HTTP 429 and per-client keys (user, API key, IP)
- Explains why bursts matter (fixed window edge-burst problem)
- Connects rate limiting to protecting backend resources and preventing abuse
Common Mistakes
- Not naming any specific rate limiting algorithm
- Confusing rate limiting with load balancing or caching
- Ignoring the burst problem at fixed window boundaries
- Forgetting to mention where limiter state is stored at scale (e.g., Redis) for distributed systems
Best Answer (HR Friendly)
“Rate limiting caps how many requests a user or client can make in a given period of time, so no single client can overwhelm the system or use more than their fair share. If someone exceeds the limit, they get a "too many requests" response and have to wait before trying again.”
Code Example
async function allowRequest(userId, capacity = 10, refillPerSec = 1) {
const now = Date.now() / 1000
const key = `rate:${userId}`
const bucket = await redis.hgetall(key) // { tokens, lastRefill }
let tokens = bucket.tokens ? parseFloat(bucket.tokens) : capacity
let lastRefill = bucket.lastRefill ? parseFloat(bucket.lastRefill) : now
const elapsed = now - lastRefill
tokens = Math.min(capacity, tokens + elapsed * refillPerSec)
if (tokens < 1) {
await redis.hset(key, { tokens, lastRefill: now })
return false // 429 Too Many Requests
}
tokens -= 1
await redis.hset(key, { tokens, lastRefill: now })
return true // request allowed
}Follow-up Questions
- What is the difference between token bucket and leaky bucket algorithms?
- Why does a fixed window counter allow bursts at window boundaries, and how does sliding window fix it?
- How would you implement rate limiting consistently across multiple servers?
- What HTTP status code and headers should a rate-limited response include?
MCQ Practice
1. What HTTP status code is conventionally returned when a client is rate limited?
HTTP 429 Too Many Requests is the standard status code for rate-limited responses.
2. Which rate limiting algorithm processes requests at a fixed, steady output rate, smoothing bursts?
Leaky bucket enqueues requests and drains them at a constant rate, smoothing out bursty input.
3. What is the main weakness of a naive fixed window counter?
A client can send the full limit at the end of one window and the full limit again at the start of the next, doubling the effective burst.
Flash Cards
What is rate limiting? — Capping how many requests a client can make in a time window to protect a service.
Token bucket? — Tokens refill at a steady rate; each request consumes one, and requests are rejected when tokens run out.
Leaky bucket? — Requests are processed at a fixed steady rate regardless of how bursty the input is.
Why rate limit an API? — To protect backend resources, prevent abuse, and ensure fair usage across clients.