Loading...
Spaceplay← →stepRreset
See how rate limiting protects an API with an interactive visualization. Watch a token bucket refill and drain, a fixed window reset at the boundary, a sliding window smooth out bursts, and requests get accepted or rejected with 429.
Loading visualization...
Rate limiting caps how many requests a client may make in a period of time. The server tracks usage per client key, accepts requests inside the budget, and answers the rest with 429 Too Many Requests and a Retry-After header.
An API without a rate limit is only as available as its most aggressive caller. A buggy retry loop, a scraper, or a credential stuffing attack can consume all of the database connections and CPU that every other client depends on. Rate limiting gives each client a budget and enforces it before the request reaches expensive code.
Every limiter answers the same question, has this key made too many requests recently, but they differ in what they store. A fixed window keeps one counter per clock-aligned window. A token bucket keeps a fractional token count and a timestamp, refilling continuously and allowing bursts up to the capacity. A sliding window log keeps the timestamp of each accepted request and counts the ones inside the last N seconds, which is exact but costs one entry per request.
The key decides what is being protected. Limiting by IP address is the default at the edge and stops anonymous floods, but shared NATs and mobile carriers put thousands of users behind one address. Limiting by API key or user id after authentication is fairer and lets you sell tiers. Many systems apply both, a loose IP limit at the load balancer and a per-account limit in the application.
The state has to be shared. A Map inside one Node process only limits that process, so three instances behind a load balancer silently triple the budget. Production limiters keep counters in Redis and run the check and the update as one atomic operation, either INCR with EXPIRE or a short Lua script, so two instances cannot both read 2 and both accept when the limit is 3.
Interview framing: define Rate Limiting in one sentence, then explain one concrete runtime behavior and one common pitfall with a short code example.
A fixed window resets at t=10, t=20, and so on, so a client can send its full budget at t=9.9 and again at t=10.1. Two adjacent windows spent at the boundary give twice the nominal rate over a short interval.
Fix: Use a sliding window log when exactness matters, or the sliding window counter approximation, prev * (1 - position) + current, when you want two integers per key and can tolerate a small error at the edges.
A Map in a Node process is invisible to the other instances behind the load balancer. Each instance enforces its own copy of the limit, so the effective limit is multiplied by the instance count and resets on every deploy.
Fix: Store the counter or bucket in Redis and perform the read, update, and write in one atomic step: INCR plus EXPIRE for fixed windows, or a Lua script for token buckets.
If a sliding log pushes the timestamp of every request, including rejected ones, a client that keeps retrying keeps pushing its own unlock time further away and can never recover, and the log grows without bound under attack.
Fix: Only accepted requests count toward the limit. Push the timestamp inside the accepted branch, and prune expired entries on every call so the log never exceeds the limit in length.
A bare 429 tells the client to stop but not for how long, so SDKs fall back to guessing, usually exponential backoff starting from a fixed value. That wastes capacity when the lockout is short and hammers the server when it is long.
Fix: Compute the seconds until the next token or slot, round up, and send it as Retry-After. Add X-RateLimit-Remaining on every response so well-behaved clients can slow down before they hit the wall.
Common interview prompts with concise model answers.
A fixed window counts requests per clock-aligned interval and resets the count at the boundary, which is cheap but lets a client double its budget by straddling the reset. A token bucket refills continuously at a fixed rate up to a capacity, so it allows a burst up to the capacity while capping the long-run average, and it has no boundary to exploit.
function allow(bucket, now, capacity = 5, ratePerSec = 1) {
const elapsed = (now - bucket.last) / 1000;
bucket.tokens = Math.min(capacity, bucket.tokens + elapsed * ratePerSec);
bucket.last = now;
if (bucket.tokens < 1) return false;
bucket.tokens -= 1;
return true;
}Keep the state in a shared store, almost always Redis, and make the check and update atomic. For a fixed window, INCR the key for the current window and set EXPIRE on the first hit; the returned value tells you whether the request is over the limit. For a token bucket, run the refill and spend in a Lua script so no other instance can interleave between the read and the write.
const key = `rl:${ip}:${Math.floor(Date.now() / 10_000)}`;
const count = await redis.incr(key);
if (count === 1) await redis.expire(key, 10);
if (count > 3) {
res.set("Retry-After", "10");
return res.status(429).end();
}
next();429 Too Many Requests means the client has exceeded its budget and the request was not processed. Retry-After tells the client how many seconds to wait, rounded up. X-RateLimit-Limit and X-RateLimit-Remaining, sent on every response, let clients pace themselves before they are rejected. The newer RateLimit-Policy header from the IETF draft standardizes the same information.
It depends on what you are protecting. IP address works for anonymous traffic at the edge but punishes users behind a shared NAT. After authentication, the API key or user id is fairer and supports per-tier limits. Sensitive endpoints such as login often combine keys, for example a per-IP limit and a per-account limit, so neither a distributed attack nor a single abusive account gets through.
Debounce and throttle run in the browser and reduce how often a cooperative client fires a call, which improves UX and saves bandwidth. They cannot protect the server, because an attacker controls the client code. Rate limiting runs on the server or at the edge and enforces the budget regardless of the client. Use throttle for typing and scrolling, and a server limiter for the API.
Continue with these concepts to strengthen your mental model.
const CAPACITY = 5, REFILL_PER_SEC = 1;const buckets = new Map(); // key -> { tokens, last } function allow(key, now) { const b = buckets.get(key) ?? { tokens: CAPACITY, last: now }; const elapsed = (now - b.last) / 1000; b.tokens = Math.min(CAPACITY, b.tokens + elapsed * REFILL_PER_SEC); b.last = now; const ok = b.tokens >= 1; if (ok) b.tokens -= 1; buckets.set(key, b); return ok;} app.use((req, res, next) => { if (allow(req.ip, Date.now())) return next(); res.set("Retry-After", "1"); res.status(429).send("Too Many Requests");});waiting
waiting
no requests yet