Implement a leaky-bucket rate limiter

Last updated: Apr 17, 2026

Quick Overview

Implement a leaky-bucket rate limiter evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Box

Implement a leaky-bucket rate limiter

Box

Aug 1, 2025, 12:00 AM

hardSoftware EngineerOnsiteSystem Design

48

0

Implement a leaky-bucket rate limiter

Implement a Leaky-Bucket Rate Limiter with Tests and Distributed Design

Context and Assumptions

Implement in a general-purpose language; the reference solution uses Python 3 for clarity and unit tests.
Leaky bucket semantics: a fixed drain rate r units/sec, a finite capacity b units. Each request consumes 1 unit unless specified otherwise. The bucket "leaks" continuously at rate r.
The limiter should support:
1. try_acquire(n=1) that returns whether a request of size n is allowed now and, if not, the wait time until it would be allowed.
2. Unit tests for steady-state, burst, and boundary conditions.
3. Discussion of concurrency safety (multi-thread/process) and distributed extension (e.g., Redis) with consistency & failure-mode considerations.

Task

Implement a leaky-bucket rate limiter enforcing a maximum average request rate with a fixed drain rate.
Write unit tests to validate:
- Steady-state behavior at/under the configured rate.
- Burst behavior up to capacity.
- Boundary/edge conditions (precision, zero/near-zero time deltas, exact thresholds).
Explain how to make the limiter safe under concurrency.
Propose a design to extend it in a distributed setting (e.g., Redis), including consistency and failure-mode considerations.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Box•More Software Engineer•Box Software Engineer•Box System Design•Software Engineer System Design

Your design canvas — auto-saved