The Leaky Bucket: Smooth and Steady

The Analogy

Imagine a physical bucket with a small hole drilled in the bottom.

• Input: You can pour water (requests) into the top as fast as you want — a trickle or a flood.
• Output: Water drips out of the hole at a constant, fixed rate, regardless of how much is inside.
• Overflow: If you pour faster than the hole drains and the bucket fills up, the extra water spills over the edge and is lost — those requests are dropped.

This analogy maps directly to the algorithm's mechanics.

How It Actually Works

The Leaky Bucket is implemented as a FIFO queue with a fixed-rate processor:

1. Incoming requests are placed into the queue (the bucket).
2. A processor dequeues and handles one request every 1/rate seconds — this is the "drip."
3. If a new request arrives and the queue is already at capacity, the request is dropped (or rejected with HTTP 429).

The critical property: the output rate is always constant. It doesn't matter if 1 request arrived or 1,000 — the downstream system sees a perfectly smooth, metered stream of work.

Incoming:  ████████████████  (burst of 16 requests)
Queue:     [r1][r2][r3]...[r10]  (capacity = 10, 6 dropped)
Output:    r1 ... r2 ... r3 ...  (one per second, evenly spaced)

Use Case: Writing to a legacy database, a mechanical disk, or any downstream service that creates high jitter or crashes under bursty load. You want to force a smooth, predictable load profile regardless of what the upstream sends.

What happens to dropped requests? They are gone. The Leaky Bucket does not retry or delay them — it discards them. The caller receives an error and must decide whether to retry. This is an important operational consideration: if your clients are not retry-aware, dropped requests mean lost work.