การเลือกอัลกอริทึมจำกัดอัตราการส่งคำขอที่เหมาะสม

A rate limit policy is only as good as the algorithm that enforces it. The same limit of 100 requests/minute behaves very differently depending on how you count.

In this lesson we compare four classic approaches and learn how to pick one based on your fairness, burst, and accuracy needs.

The simplest approach: count requests in a fixed time window (for example each calendar minute) and reset the counter at the boundary.

• Pros: trivial to implement, low memory
• Cons: allows a burst of 2x the limit around the window edge

With a fixed window, a client can send limit requests at 00:59 and another limit at 01:00. That is double the intended rate in a one-second span.

Sliding window algorithms exist to smooth out exactly this spike.

Store a timestamp for every request. To decide, drop timestamps older than the window and count what remains.

• Pros: exact, no boundary burst
• Cons: memory grows with request volume

A hybrid: keep the current and previous fixed-window counts, then estimate the rate using a weighted overlap.

It approximates the sliding log with far less memory, which is why API gateways and CDNs favor it.

A bucket holds tokens up to a capacity. Tokens refill at a steady rate; each request spends one token. Empty bucket means reject.

• Allows controlled bursts up to the bucket capacity
• Smooths the long-term average to the refill rate

Requests enter a queue that leaks at a constant rate. If the queue overflows, requests are dropped.

Unlike the token bucket, the leaky bucket enforces a steady output rate — ideal when a downstream service cannot handle spikes.

• Token bucket lets traffic burst up to capacity, then throttles — good for user-facing APIs that should feel responsive.
• Leaky bucket forces a smooth, constant flow — good for protecting fragile backends.

Pick based on constraints:

• Lowest memory: fixed window
• Highest accuracy: sliding window log
• Best balance: sliding window counter
• Burst-friendly: token bucket

Across many servers, each node cannot keep its own counter or you multiply the real limit. Use a shared store like Redis with atomic operations so the count is global.

Token bucket and sliding window counter both map cleanly to Redis primitives.

Ask:

• Do I need to allow short bursts? → token bucket
• Must downstream see a steady rate? → leaky bucket
• Is exactness critical for billing? → sliding window log
• Do I want simple and cheap? → fixed or sliding window counter

Test your understanding of algorithm selection.

You compared four rate limiting algorithms:

• Fixed window — cheap but allows edge bursts
• Sliding window — accurate, smooths boundaries
• Token bucket — burst-friendly, averages out
• Leaky bucket — constant output rate

Choose based on burst tolerance, accuracy, and memory budget.