Top 9 Rate limiting Interview Questions
Browse 9 real-world technical and behavioral interview questions about Rate limiting. Review scenarios, edge cases, and architectural best practices.
Design a notification system that sends 50 million messages a day across email, SMS and push.
A notification system at 50 million a day is sized by bursts and provider limits, not its average of about 580 a second. Accept with an idempotency key, apply preferences once, fan out to per-channel queues with transactional and bulk lanes, rate-limit each provider, and never fail over blindly on a timeout.
Rate-limit an LLM gateway where one request can cost a hundred times another.
Rate limiting an LLM gateway by request count fails because cost is tokens, and output tokens are unknown at admission. Budget tokens per tenant, reserve input plus expected output, settle against reported usage when the stream ends, cap concurrent streams, and cancel upstream on disconnect.
Your rate limiter has to work across twenty gateway instances. What does Redis do, and what breaks first?
Redis gives twenty gateways one counter mutated atomically through INCR or a Lua script, so rate limiting is fleet-wide. What breaks first is usually latency, not throughput: a slow Redis stalls every request for its timeout. Hot keys, caller clocks inside scripts and counts lost on async failover follow.
You must ingest all of English Wikipedia every day, and the source does not want to be hammered. What runs, how often, and what do you do about the run that fails at hour six?
Do not re-download Wikipedia daily. Use incremental ingestion: load the published dump once, follow the recent-changes feed, and fetch only the latest revision of each changed page in small, polite batches. Checkpointing each batch behind a revision-guarded write lets a run that fails at hour six resume.
Your public GraphQL endpoint lets one client send a query ten levels deep, and it takes the database down. How do you stop that without breaking legitimate clients?
Estimate GraphQL query cost before execution, multiplying list fields by their enforced page size, and reject anything over budget. Add a depth limit as a backstop, persisted queries for your own apps, execution timeouts, and per-client rate limits counted in cost points, not requests.
One tenant bursts to ten times their normal traffic and every other customer's latency doubles. Your global rate limit was never hit. How would you design for fairness instead?
A global limit protects the service from overload but says nothing about how capacity is divided, so one tenant can consume most of it while staying under the ceiling. Fairness needs per-tenant accounting: a token bucket for the steady-state contract, a concurrency limit so expensive requests cannot hog workers, and round-robin queueing so a burst queues behind itself.
Design a rate limiter that allows N requests per client per minute. Write the class.
A rate limiter machine coding solution should reject fixed-window boundary bursts, usually with a token bucket. It needs no per-request history and stores two numbers per client, but only if refill is computed lazily from a timestamp rather than by running a background thread. Use this rate limiting answer to show the decision, trade-off, and evidence rather than a memorised definition.
Your rate limiter runs in five regions with a cap of 100 requests a minute per user. One user gets 500 through. Where did the counting go wrong?
Global rate limiting fails when each region owns a local counter, because five regions each allowing 100 requests creates a 500-request ceiling. Use one atomic shared counter, route each user to an owning region, or lease regional budget deliberately. It also connects distributed counters to the point an interviewer is testing.
You need to enforce 100 requests per minute per API key across a fleet of forty servers. Which limiting algorithm, and where does the counter live?
Fixed windows permit twice the limit across a boundary; the two sliding windows fix that at a memory or an accuracy cost; token bucket permits a bounded burst and leaky bucket smooths output instead. Across a fleet the counter must sit in one store mutated atomically, or each node silently enforces its own limit.