Leaky Bucket Rate Limiting Algorithm

Introduction

Leaky Bucket is a rate limiting algorithm used to control how quickly requests are processed by a system. It is useful when incoming traffic is bursty, but the backend service should receive requests at a steady and predictable rate.

The core idea is simple: requests enter a fixed-size bucket or queue, and they leave the bucket at a constant rate. If too many requests arrive and the bucket becomes full, extra requests are dropped.

What Is Leaky Bucket?

Leaky Bucket uses a queue with fixed capacity. Every incoming request first enters this queue instead of directly reaching the backend server.

Requests then leave the queue through an outlet at a fixed rate. This means the backend receives traffic smoothly, even if the incoming traffic arrives suddenly in large bursts.

For example, a bucket may be configured with:

• Bucket capacity: 1,000 requests

• Output rate: 100 requests per second

If 500 requests arrive suddenly, they can wait inside the bucket and leave gradually. But if the bucket is already full, new requests cannot be stored and are rejected.

How Leaky Bucket Works

A simple flow looks like this: Request arrives => Enters bucket => Waits in queue => Leaves at constant rate

The working can be understood in these steps:

• Fixed bucket is created: A queue with limited capacity is maintained.

• Requests enter the bucket: Incoming requests are placed into the queue.

• Requests leave steadily: The system forwards requests at a fixed configured rate.

• Extra requests wait: If requests arrive faster than the output rate, they remain in the queue.

• Overflow gets dropped: If the queue becomes full, new incoming requests are rejected.

Rejected API requests may commonly receive: HTTP 429 Too Many Requests

Why Leaky Bucket Smooths Traffic

Leaky Bucket is mainly used for traffic shaping. It converts uneven incoming traffic into a steady output rate.

Even if requests arrive unpredictably, they leave the bucket in a controlled manner. This protects downstream systems such as APIs, databases, cache servers, payment services, and internal microservices from sudden overload.

The tradeoff is delay. Since requests may wait inside the queue, latency can increase when traffic bursts are large.

What Happens When the Bucket Is Full?

The bucket has limited capacity, so it cannot store unlimited requests. If requests arrive faster than they leave for a long time, the queue eventually becomes full.

Once the bucket is full:

• New requests cannot enter the queue.

• Extra requests are dropped or rejected.

• The backend still receives traffic only at the configured output rate.

• The system remains protected from overload.

This behavior is important because unlimited queues can create very high latency and memory pressure.

Leaky Bucket vs Token Bucket

Leaky Bucket and Token Bucket are both used for rate limiting, but they handle bursts differently.

Leaky Bucket is stricter about output rate. Token Bucket is more flexible because it allows short bursts.

Advantages and Limitations

Leaky Bucket is useful when the backend must be protected from sudden traffic spikes.

• Smooth traffic flow: Bursty input becomes steady output.

• Backend protection: Services receive requests only at a safe configured rate.

• Simple behavior: Queue requests and release them steadily.

• Useful for traffic shaping: Works well when constant flow is more important than burst flexibility.

• Added latency: Requests may wait in the queue during bursts.

• Possible request drops: If the bucket is full, extra requests are rejected.

• Less burst-friendly: It does not allow sudden large bursts like Token Bucket.

Summary

Leaky Bucket is a rate limiting and traffic shaping algorithm that uses a fixed-size queue to regulate requests. Incoming requests enter the bucket, and the system forwards them at a constant rate.

If requests arrive too quickly, they wait in the queue. If the queue becomes full, extra requests are dropped. This makes Leaky Bucket useful for smoothing bursty traffic, protecting backend services, and keeping request processing stable.