How to Explain a Rate Limiter in English

The prompt

Design a rate limiter for a public API. Talk through it in English. Do not draw. In 60–90 seconds cover who you limit, how you count, where the limiter sits, and one trade-off.

How to explain it

1. 1. Requirements

   Who the user is, and what must work on day one.

   Clarify identity, write vs read, and one thing you are not building yet.

2. 2. Scale

   One rough number you can say out loud.

   QPS, storage, or “millions of keys.” The number can be rough. The sentence cannot be missing.

3. 3. API

   Name the two or three calls.

   “I would expose allow(userId) and a 429 when they are over the limit.”

4. 4. Data

   Where the state lives.

   Cache, database, or log. Say why that store, not a tool dump.

5. 5. Bottleneck

   What breaks first when traffic grows.

   Hot key, single leader, clock skew. Invite a follow-up.

6. 6. Trade-off

   What you gain and what you give up.

   Accuracy vs speed, consistency vs availability. One pair is enough.

• “Let me start with requirements.”
• “I would rate-limit by API key.”
• “I would return 429 with a retry-after.”
• “The trade-off is smoothness versus a simpler window.”

Practise out loud

Model spoken script

Let me start with requirements. I would rate-limit by API key, not by IP, so one office NAT does not lock a team out. Say 100 requests a minute to start. I would expose a check before the handler, and return 429 with a retry-after. State lives in Redis so every instance sees the same count. The bottleneck is a hot key if one customer is huge. The trade-off is token bucket — smoother traffic — versus a fixed window, which is simpler but bursts at the edge of the window.