Sweaty Imposter

Leaky Bucket

TechniqueThroughput and FlowMidSeniorUpdated
Requests enter a queue, processed at fixed rate. Smooths out bursts entirely, no spike ever reaches downstream.

When to Use Leaky Bucket

When the downstream cannot handle bursts at all (legacy DB, third-party with strict queries per second (QPS)). Token bucket allows bursts; leaky bucket guarantees a smooth rate.

In Practice

Outbound webhook delivery: enqueue, drain at N per second so the receiver isn't slammed. Many billing systems use it for outbound API calls to providers.

How Leaky Bucket Comes Up in Interviews

Scenario

You're delivering outbound webhooks to customers whose receivers can't handle bursts at all, any spike causes 503s. You need a fixed egress rate with zero burstiness reaching the receiver. Which algorithm?

Leaky bucket queues requests and drains at a fixed rate, guaranteeing a smooth output regardless of input burstiness. Token bucket would let bursts through up to the bucket size, wrong for fragile receivers.

Leaky bucket queues incoming requests and drains them at a fixed rate, smoothing input bursts to a perfectly steady output, which is exactly what you want when the receiver can't handle bursts at all. The implementation is a FIFO queue plus a fixed-rate drain timer. Token bucket would let a burst through up to the bucket size, which a fragile receiver can't tolerate. Many webhook-delivery systems (Stripe, GitHub) and outbound-API integrations to legacy systems use leaky bucket internally. The tradeoff is latency: queued requests wait for their turn at the drain, so individual request latency increases when the input rate exceeds the drain rate.

Where It Comes Up