Skip to content

Multi-Tier Rate Limiting Service

Published 3 October 2026

Problem statement

The task was to build a rate-limiting service where different clients could belong to different service tiers, such as:

  • free
  • pro
  • enterprise

Each tier could have a different rate limit. A client sends requests using an identifier, and the service needs to determine the client's tier and enforce the corresponding limit. Requests exceeding the configured limit should be rejected.

An important requirement was that tier limits could be updated at runtime without restarting the service. The interviewer also clarified that if a client had no valid tier configuration, the implementation should fall back to a global default policy. Either default-deny or default-allow behavior was acceptable as long as it was defined consistently.

Follow-ups

  • Rate limiting algorithm trade-offs. After discussing the implementation, the interviewer asked why I chose a particular rate-limiting algorithm and how it compared with alternatives. The discussion focused on the trade-offs among different rate-limiting approaches rather than only producing working code. I used a token-bucket-style design for the implementation.
  • Testing. Once the implementation was complete, the interviewer asked me to add tests and verify that the rate limiter behaved correctly. One issue was that the behavior depended on elapsed time, making some refill scenarios difficult to test using the real system clock. The discussion covered controlling time during tests, such as using a mockable or injected clock instead of depending directly on real wall-clock timing.
  • Runtime configuration changes. The interviewer also paid attention to how existing client state behaved when a tier configuration changed at runtime. For example, changing a tier's limit needed to interact correctly with any already-existing rate-limiter state rather than simply restarting or recreating the entire service.
  • Distributed rate limiting. The final discussion changed the system from a single process with in-memory state to a cluster of rate-limiter instances. The interviewer asked how the design would need to evolve when multiple servers were independently receiving requests but still needed to enforce a consistent client rate limit.