What is rate limiting and throttling in a REST API and why are they important?
Understand rate limiting vs throttling in REST APIs: token bucket, sliding window, the 429 status, Retry-After headers, and why they protect your API.
Expected Interview Answer
Rate limiting caps how many requests a client may make to a REST API within a time window, and throttling slows or delays requests that exceed that cap, together protecting the API from overload and abuse.
The server tracks requests per client (by API key, token, or IP) using algorithms like fixed window, sliding window, token bucket, or leaky bucket. When a client crosses the limit it typically receives an HTTP 429 Too Many Requests response, often with a Retry-After header and headers such as X-RateLimit-Remaining. This preserves capacity for all users, enforces fair usage, and defends against scraping and denial-of-service.
- Prevents server overload from traffic spikes
- Ensures fair usage across all clients
- Mitigates abuse, scraping and brute-force attacks
- Protects downstream services and databases
- Gives predictable, communicable limits via headers
AI Mentor Explanation
Think of the over limit in a one-day cricket match: a single bowler may bowl only ten overs no matter how good they are. Once they hit that cap, the captain must bring on someone else. Rate limiting is that over quota for an API client: each caller gets a fixed allowance in a window, and once used up the server stops accepting more until the next allocation opens.
Step-by-Step Explanation
Step 1
Identify the client
Attribute each request to an API key, user token, or IP so limits are counted per caller.
Step 2
Choose an algorithm
Pick fixed window, sliding window, token bucket, or leaky bucket based on burst tolerance needs.
Step 3
Define the quota
Set the number of allowed requests per time window, possibly by plan tier.
Step 4
Track counts
Store per-client counters, often in a fast store like Redis, updated on each request.
Step 5
Respond on breach
Return 429 Too Many Requests with Retry-After and X-RateLimit-* headers so clients can back off.
What Interviewer Expects
- Clear distinction between rate limiting and throttling
- Knowledge of the 429 status and Retry-After header
- Familiarity with token bucket / leaky bucket algorithms
- Understanding of per-client identification
- Reasons: abuse prevention, fairness, stability
Common Mistakes
- Confusing rate limiting with authentication or authorization
- Returning 500 or 503 instead of the correct 429 status
- Applying limits globally instead of per client
- Ignoring burst handling, causing legitimate spikes to fail
- Not exposing limit headers so clients cannot back off gracefully
Best Answer (HR Friendly)
“Rate limiting sets a maximum number of requests a user can make to an API in a given time, and throttling slows down anyone who goes over. Together they stop the system from being overloaded and keep it fair and fast for everyone.”
Code Example
const rateLimit = require('express-rate-limit')
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // 100 requests per window per IP
standardHeaders: true, // adds RateLimit-* headers
legacyHeaders: false,
message: { error: 'Too many requests, please try again later.' },
})
app.use('/api/', limiter)Follow-up Questions
- Compare token bucket and leaky bucket algorithms.
- What is the difference between a fixed and sliding window?
- Which HTTP status and headers signal a rate limit?
- How would you rate limit in a distributed, multi-server setup?
- How do you give different limits to different plan tiers?
MCQ Practice
1. Which status code indicates a rate limit was exceeded?
HTTP 429 Too Many Requests is the standard response when a client exceeds its allowed rate.
2. Which algorithm allows short bursts while capping the average rate?
The token bucket accumulates tokens, permitting bursts up to bucket size while limiting the sustained rate.
3. Which header tells a client when to retry?
Retry-After tells the client how long to wait before making another request after a 429.
Flash Cards
Rate limiting vs throttling — Rate limiting caps requests per window; throttling slows or delays requests over the cap.
Rate-limit status code — HTTP 429 Too Many Requests, usually with a Retry-After header.
Token bucket idea — Each request spends a token; tokens refill over time, allowing bursts up to bucket size.
Why per-client limits? — So one abusive caller cannot starve capacity for everyone else.