What the interviewer just asked
You paused after the prompt. Now gather requirements — write them on the board so the interviewer can course-correct early.
Functional questions to ask
- What are we rate-limiting? API endpoints? Users? IPs? API keys?
- What happens when the limit is hit? Reject (429)? Queue? Throw?
- Do different APIs have different limits?
- Do different clients have different limits? (premium tiers, internal services)
- Should the client know when to retry? (
Retry-After/ remaining quota) - Is there a default when nothing is configured for an API?
Non-functional questions
- In-memory only, or distributed? Start in-memory unless they insist.
- Single-threaded or multi-threaded? Almost always multi-threaded.
- Rough scale? How many APIs / clients — guides memory choices (log vs counter).
- Do limits reset / refill? Window length and refill rate matter for the algorithm.
What you produce on the board
Functional
- Client calls an API; within limit → allow + remaining quota
- Over limit → reject + retry-after
- Per-API configuration
- Per-client override
- Default limit when an API is unregistered
Non-functional
- Thread-safe
- In-memory for v1 (no DB / Redis required in the first cut)
- Fast hot path (aim O(1) per request)
- Extensible — new algorithms without rewriting the Manager
Out of scope (say explicitly)
- Distributed rate limiting across pods (discuss later)
- Persistence across restarts
- Admin UI for config
Scope sentence you can say out loud
“I’ll build a thread-safe in-memory limiter with pluggable algorithms, per-API config and per-client overrides, returning allow/reject with remaining and retry-after. Distributed Redis comes after the single-JVM design is solid.”