Rate Limiter bucket logic

Q: Rate Limiter bucket logic

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the exact "3 allowed, 2 rejected" result and the post-refill behavior below were both actually run, with real elapsed timing, not calculated in the abstract. ## 1. The problem, restated Implement a token bucket: it starts with `capacity` tokens, each successful request consumes one, and tokens refill continuously at `refillRatePerSec` — a request is allowed only if at least one (or `cost`, for a variable-cost request) token is currently available. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Continuous refill, or discrete steps (e.g. reset every second)? | Continuous refill is genuinely smoother and more common in real systems — worth confirming, not assuming. | | Variable request cost? | Determines whether `tryConsume` needs a `cost` parameter beyond a fixed 1. | | Per-client or global bucket? |

The problem

Problem, as an interviewer would state it: "Implement a rate limiter using the token bucket algorithm — a bucket holds up to N tokens, each request consumes one, and tokens refill continuously over time. Show me it correctly rejects requests once the bucket is empty, and correctly allows more after tokens refill."

Examples:

Code

const limiter = createTokenBucket({ capacity: 3, refillRatePerSec: 10 });
limiter.tryConsume(); // true, true, true, then false, false for 5 rapid calls

Clarifying questions expected:

Should tokens refill continuously (fractional tokens accumulating smoothly) or in discrete steps?
Can a single request cost more than one token?
Is this rate limiter meant to run per-client (one bucket each) or globally (one shared bucket)?

Code / implementation expected: Yes — real, direct proof that exactly the bucket's own capacity worth of rapid requests are allowed, the rest genuinely rejected, and more become available after a real, measured refill period.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: the exact "3 allowed, 2 rejected" result and the post-refill behavior below were both actually run, with real elapsed timing, not calculated in the abstract.

1. The problem, restated

Implement a token bucket: it starts with capacity tokens, each successful request consumes one, and tokens refill continuously at refillRatePerSec — a request is allowed only if at least one (or cost, for a variable-cost request) token is currently available.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Continuous refill, or discrete steps (e.g. reset every second)?	Continuous refill is genuinely smoother and more common in real systems — worth confirming, not assuming.
Variable request cost?	Determine

The solution is hidden so you can try first

4 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a token-bucket rate limiter allows exactly capacity-many rapid requests, then correctly allows more after a real, measured refill