Coursify

Differences Between Leaky Bucket and Token Bucket Algorithms (Traffic Shaping vs Rate Limiting)

Differences Between Leaky Bucket and Token Bucket Algorithms (Traffic Shaping vs Rate Limiting)

Verified Sources
Sep 12, 2026

Leaky bucket and token bucket are both classic mechanisms for keyword traffic shaping and keyword rate limiting, but they differ in what resource is constrained and how they react to burstiness: leaky bucket smooths output to a constant rate (often by queueing and draining or by a “meter” variant), while token bucket grants “credit” (tokens) that permits controlled bursts up to a maximum bucket capacity.2

Key terms you’ll keep reusing:

  • keyword token bucket
  • keyword leaky bucket
  • keyword bucket capacity (burst size)
  • keyword sustained rate

Footnotes

  1. Rate-limiting algorithms compared: token bucket, leaky ... (Arcjet) - Compares token bucket (credit) vs leaky bucket (constant emission/queue) and burst behavior. ↩

  2. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩

Token Bucket vs Leaky Bucket (Georgia Tech / Udacity)

At a high level:

  • Token bucket: tokens accumulate up to a limit; if enough tokens exist, you can send immediately—even if arrivals were bursty earlier. This makes it ideal when you want to absorb bursts while still enforcing a bounded average rate.2
  • Leaky bucket: packets are emitted at a constant “leak” rate. Excess work either waits in a queue (queue-based shaping) or is discarded if the bucket/buffer is full, resulting in smoothed output and less burst transmission.2

Footnotes

  1. Rate-limiting algorithms compared: token bucket, leaky ... (Arcjet) - Compares token bucket (credit) vs leaky bucket (constant emission/queue) and burst behavior. ↩

  2. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩ ↩2

  3. Leaky Bucket & Token Bucket - Traffic shaping (Slideshare) - Provides practical descriptions: constant output for leaky bucket, burst allowance for token bucket, and buffer overflow behavior. ↩

Behavioral Differences (Qualitative)

Higher = more of that property

Mechanistic core (what changes over time)

Token bucket

  1. Tokens are generated at a fixed rate (refill rate).
  2. Each packet/request consumes tokens.
  3. Tokens accumulate up to a maximum capacity; beyond that, additional would-be tokens are discarded.2

Leaky bucket

  1. Arrivals are stored in a bucket/queue (or tracked as a “water level” in the meter interpretation).
  2. The bucket is drained at a constant leak rate to produce output.
  3. If the bucket is full, new arrivals may be dropped (queue variant) or are not allowed to increase backlog beyond the defined limit.2

This is why token bucket is often described as allowing bounded burstiness, while leaky bucket is described as smoothing bursty input into a steady stream.2

Footnotes

  1. Rate-limiting algorithms compared: token bucket, leaky ... (Arcjet) - Compares token bucket (credit) vs leaky bucket (constant emission/queue) and burst behavior. ↩

  2. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩ ↩2 ↩3

  3. Leaky Bucket & Token Bucket - Traffic shaping (Slideshare) - Provides practical descriptions: constant output for leaky bucket, burst allowance for token bucket, and buffer overflow behavior. ↩ ↩2

Simulating both algorithms for the same burst

  1. 1
    Step 1

    Choose token refill rate rr, token bucket capacity bb; for leaky bucket choose leak/service rate rr and bucket/queue capacity BB.

  2. 2
    Step 2

    At time t=0t=0, let kk requests arrive at once (a burst larger than what a steady-rate sender could handle).

  3. 3
    Step 3

    Refill would have produced tokens from the previous idle/earlier intervals; each request requires 1 token. Allow requests until tokens run out; reject/deny the rest.

  4. 4
    Step 4

    Enqueue up to BB (or cap the water level). Emit at the constant leak/service rate. If arrivals exceed BB, the extra arrivals are dropped or delayed depending on the variant.

  5. 5
    Step 5

    Token bucket outputs a burst immediately (up to bb credit), then throttles once tokens are exhausted. Leaky bucket produces a more uniform release rate (and may incur queueing delay until the leak catches up).

Exact differences that matter in practice

Pro Tip: Burst behavior is the deciding factor

If you want to let clients/flows burst up to a configured maximum, token bucket aligns better. If you need to smooth output arrivals to protect burst-intolerant downstream systems, leaky bucket aligns better.2

Footnotes

  1. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩

  2. Leaky Bucket & Token Bucket - Traffic shaping (Slideshare) - Provides practical descriptions: constant output for leaky bucket, burst allowance for token bucket, and buffer overflow behavior. ↩

1) Burst handling: credit vs smoothing

  • Token bucket permits bursts because tokens can accumulate during idle or lower-traffic periods; after that, each request must “pay” one token, so bursts are bounded by capacity.2
  • Leaky bucket limits output by draining at constant rate; a burst becomes either queueing delay or loss (depending on whether you shape by delay or police by dropping).2

These statements align with standard descriptions: leaky bucket is used to smooth traffic into fixed rate output, while token bucket permits controlled burstiness.2

2) Output pattern: jitter and immediate transmission

A queue-based leaky bucket variant tends to produce less bursty emission (more regular spacing), because it emits at a constant drain rate after storing/accumulating input. Token bucket may output more burst at decision time (when tokens exist), then revert to the long-term rate once tokens are depleted.2

3) Memory/state: queue depth vs credit counters

  • Token bucket stores a small amount of state: token count (and timing/refill logic). A queue-based leaky bucket stores backlog (queue depth / waiting work) until it drains, which can require more memory.2
  • Rate-limiting system comparisons commonly emphasize token bucket as “credit storage,” while leaky bucket queue variant stores “work/backlog.”2

4) Queueing vs rejection (application-level outcomes)

Many modern rate limiters prefer rejection over waiting, especially at APIs, because queueing can increase latency and tie up resources. When leaky bucket is used in a shaping sense, queueing is expected; when used as a policing mechanism, nonconforming traffic is dropped.2
Cisco’s description notes token buckets are used to regulate traffic for policing/shaping, and discusses how burstiness is permitted but bounded for shaping.

5) Bounding guarantees: long-term average vs immediate allowance

For token bucket used as a meter/regulator, a token bucket “bounds burstiness” and enforces the long-term rate not exceeding the refill rate plus burst credit.2
For leaky bucket, the core operational guarantee is that the system drains at a constant rate, turning bursty arrivals into a steadier output stream.2

Footnotes

  1. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. Rate-limiting algorithms compared: token bucket, leaky ... (Arcjet) - Compares token bucket (credit) vs leaky bucket (constant emission/queue) and burst behavior. ↩ ↩2 ↩3 ↩4

  3. Leaky Bucket & Token Bucket - Traffic shaping (Slideshare) - Provides practical descriptions: constant output for leaky bucket, burst allowance for token bucket, and buffer overflow behavior. ↩ ↩2 ↩3 ↩4

  4. Chapter: Policing and Shaping Overview (Cisco) - Discusses token bucket usage for policing/shaping and bounding burstiness with guarantees. ↩ ↩2

Common confusions (and how to resolve them)

Decision Roadmap: Choosing Token vs Leaky Bucket

Define tolerance for bursts

Step 1

If bursts must be absorbed (bounded), lean token bucket."

Define your smoothing requirement

Step 2

If downstream sees damage from bursty arrivals, lean leaky bucket."

Decide delay vs rejection

Step 3

Queue-based leaky bucket implies waiting; many API limiters instead reject."

Set parameters consistently

Step 4

Match long-term rate rr; choose burst/queue capacity to control allowed extremes."

Visual intuition with a token-credit example

Let the token bucket refill at rate rr with capacity bb. If traffic is idle before the burst, the bucket can hold up to bb tokens; thus up to bb requests can be served immediately at burst time. After that, the system throttles to the refill rate.2

Conversely, a leaky bucket with leak rate rr will output requests at a steady pace. A burst fills the buffer up to capacity; if it exceeds capacity, excess is dropped. Therefore, token bucket tends to produce early throughput spikes, while leaky bucket tends to produce regularized throughput (or delayed output).2

Footnotes

  1. Token Bucket vs Leaky Bucket (Apurva Agrawal, Medium) - Summarizes key differences: burst handling and smoothing/constant output. ↩ ↩2

  2. Rate-limiting algorithms compared: token bucket, leaky ... (Arcjet) - Compares token bucket (credit) vs leaky bucket (constant emission/queue) and burst behavior. ↩

  3. Leaky Bucket & Token Bucket - Traffic shaping (Slideshare) - Provides practical descriptions: constant output for leaky bucket, burst allowance for token bucket, and buffer overflow behavior. ↩

Knowledge Check

Question 1 of 4
Q1Single choice

Which algorithm explicitly uses accumulated “credit” (tokens) to allow short bursts while enforcing an average rate?

Explore Related Topics

1

Transmission Delay Independence Question (Length vs Distance vs Rate)

2

Compare and Contrast Between Linked and Indexed Disk Allocation Strategies

Linked and indexed allocation are non‑contiguous disk‑space strategies that both eliminate external fragmentation, but they differ in pointer placement and access performance.

  • Linked allocation stores a next‑block pointer in every data block, giving excellent sequential access and simple growth, yet random access costs O(k)O(k) for the kk‑th block.
  • Indexed allocation keeps all block addresses in a separate index block, enabling direct O(1)O(1) lookup of any logical block but incurring higher metadata overhead, especially for small files.
  • Metadata risk is split: a broken link can truncate a linked file, while a corrupted index block can hide the entire file.
  • Indexed schemes scale better for large files using multilevel indexes; linked schemes remain flexible for unpredictable growth.
  • Modern systems favor indexed or hybrid inode‑based designs for their balanced random‑access capability and extensibility.
3

Lexical Analysis and the Main Structure Used: Finite Automata

Lexical analysis relies on finite automata—typically deterministic finite automata (DFA)—to recognize token patterns defined by regular expressions.

  • Regular expressions for identifiers, numbers, etc., are converted to NFAs then to a DFA for fast scanning.
  • The DFA processes the source character by character, tracking a single current state and emitting a token at each accepting state.
  • Queues, stacks, and trees support other compiler phases (parsing, AST construction) but are not the primary model for token recognition.
  • Lexers output a stream of tokens that the parser consumes for syntax analysis.
Browse all research articles