How the interviewer opens it
“Design a rate limiter for our public API. We want to stop any single client from overwhelming the system, while normal users never notice it exists.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- who is limited / identity
- limit value
- over-limit behavior
- scale
- accuracy
- latency budget
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Limit requests per client per time window
- Reject over-limit requests with a clear signal
- Work across many gateway servers
Usually out of scope
- Full DDoS protection at the network layer
- Billing/quota purchasing
What interviewers probe
- Algorithm choice
- Each algorithm trades accuracy, memory and burst behavior differently.
- Distributed counting
- Many gateways see parts of one client's traffic; read-modify-write races.
- Failure modes
- The limiter is in the hot path of every request.
Common mistakes
- Queueing over-limit requests
- Placing the limiter deep in the stack
- No Retry-After, causing retry storms
- Ignoring multi-gateway double counting
The bar by level
- Mid-level (L4/E4)
- Explains at least two algorithms with trade-offs, puts the limiter at the gateway, uses Redis for shared state.
- Senior (L5/E5)
- Atomicity, sharding, fail-open vs fail-closed, per-endpoint rules, quantified memory, latency budget.
- Staff (L6+/E6+)
- Multi-region semantics (global vs local limits), local+sync hybrid, operability (rule rollout, observability of throttling), abuse vs fairness policy.