Implement a leaky-bucket rate limiter

Read the full interview experience this question came from →

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.

Implement a leaky-bucket rate limiter

Company: Box

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Implement a leaky-bucket rate limiter that enforces a maximum average request rate with a fixed drain rate. Write unit tests to validate steady-state, burst, and boundary conditions. Discuss how you would make the limiter safe under concurrency (multiple threads/processes) and how you would extend it for a distributed setting (e.g., shared state via Redis or a durable store), including consistency and failure-mode considerations.

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.

Read the full Box Software Engineer interview experience this question came from

|Home/System Design/Box
Box logo
Box
Aug 1, 2025
hardSoftware EngineerOnsiteSystem Design
51
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

  1. Implement a leaky-bucket rate limiter enforcing a maximum average request rate with a fixed drain rate.
  2. 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).
  3. Explain how to make the limiter safe under concurrency.
  4. Propose a design to extend it in a distributed setting (e.g., Redis), including consistency and failure-mode considerations.

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