How would you limit each user to 100 requests a minute? Compare a fixed window with a sliding window.

Fixed window: one counter per user per minute (rate:user42:10:31). Increment on each request; reject above 100; the key expires after the minute. Cheap and simple. Sliding window log: store the timestamp of every request and count those in the last 60 seconds. Exact, but stores up to 100 entries per user. Sliding window counter: keep this minute's and last minute's counts and weight them by how far into the minute you are. Nearly exact with two numbers. Return 429 Too Many Requests with Retry-After and headers showing the remaining quota, so well-behaved clients can slow down.

System design round

Design a Rate Limiter

A rate limiter looks like one counter and an if statement. The interview is about where the counter lives once there are many servers, what it costs per request, and what you do when the store holding it disappears.

Estimate, draw your design, run its traffic through it and see which boxes break. Then answer the follow-up questions. The load test is free and needs no account; an AI review or score uses one of your AI replies.

The brief

It must

Each user may make 100 requests a minute; past that, the API answers 429 Too Many Requests.
The limit holds across every API server, not per server.
Checking the limit adds at most a millisecond or two to a request.
Decide in advance what happens when the counter store is down.

The numbers

Assume 2 million active users.
At the peak, 200,000 requests a second reach the API.
Today there are 20 API servers, each counting in its own memory.

Before you draw: the numbers

Interviewers expect a quick estimate first, because the numbers decide the design. Write yours, then check.

The load test uses round numbers per box, the kind you would use on a whiteboard, so it shows where a design breaks and roughly by how much, not exact figures. How it works

The follow-up questions

Once your design is up, the interviewer goes deeper. Each question changes one thing and is a level further, Fresher to Senior. An AI interviewer scores your answer; 6 out of 10 or more climbs the rung.

Rate limiter

Not climbed yet

Our design, and why

Try your own first. “Our design” on the board shows it as boxes you can load-test.

With 20 servers each counting in memory, a user gets 100 requests per server: 2,000 a minute. The count has to live in one place every server shares, and that place has to keep up with every request: 200,000 operations a second.

The check sits in the gateway, before any business logic runs, so a request over the limit costs almost nothing.
Redis holds the counters: INCR the user’s key for this minute and set its expiry in the same Lua script, so the check is atomic. One node does about 100,000 operations a second, so three, sharded by user id.
A replica per shard, so one node dying does not drop every counter on it.
Fail open for ordinary limits when Redis is unreachable, with a short timeout on the call. Fail closed for logins, OTPs and paid AI calls, where no limit means abuse or a bill.

Past the basics: a fixed window lets a user send 100 requests at 10:00:59 and 100 more at 10:01:00. A sliding-window counter or a token bucket fixes that, still with one or two numbers per user in Redis.

What each level is expected to cover

The AI review grades your board against these.

Fresher

A counter per user per window.
Answer 429 with Retry-After when over the limit.

SDE 1

A shared store (Redis) instead of per-server memory.
An atomic increment and expiry (Lua or MULTI).

SDE 2

The burst at window edges, and a sliding window or token bucket to fix it.
Sizing Redis from the operations per second, and sharding by user.
Where the check runs (gateway) and its latency cost.

Senior

Fail open versus fail closed, chosen per endpoint.
A local fallback limiter, timeouts on the Redis call, and alerting.
Approximate counting with periodic sync when one round trip per request is too much.

How the load test works

Each round sends a few kinds of traffic from its users, at the rates in the brief. The test follows your arrows: a CDN answers what it can cache, a load balancer spreads requests, a service runs the logic and checks a cache beside it before the database, and a queue takes work off the request so the boxes after it work at their own pace.

Every box takes a rough number of requests a second (one service machine about 5,000, one Redis node about 100,000, one SQL primary about 3,000 writes, one row about 200 updates). A box asked for more turns red and drops the excess, unless a queue in front holds it back, in which case the queue grows and the work waits. Failure scenarios take machines away; a standby copy covers one.

It cannot see correctness: idempotency, consistency, and what users see when something fails. Write those in a box’s note; the AI review reads them.