Design an API Rate Limiter, from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
You run the public REST API of a developer platform. Customers authenticate with API keys and buy plans: Free at 60 requests a minute, Pro at 600, and Enterprise at whatever sales negotiated. Last month a Pro customer shipped a client with a tight retry loop, and the flood of requests pinned the primary database for forty minutes. Every customer was affected.
The API runs as 20-60 stateless instances behind a load balancer that cannot do custom limiting. A Redis cluster is available in the same region. Your task is a rate limiter that the business can trust and customers can understand.
What the interviewer would tell you if you asked
- 20-60 API instances (autoscaled), about 40,000 requests a second at peak across ~50,000 active keys.
- Redis cluster in-region with ~0.3 ms round trips.
- The API's p99 latency budget is 150 ms; the primary database is the resource being protected.
- Authenticated requests carry an API key; unauthenticated ones can only be identified by IP.
- IPs are shared (corporate NAT, mobile carriers) and can be rotated by attackers.
- Instance clocks are NTP-synchronized to within milliseconds but can still disagree.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.