Rate Limiting Algorithms: Counter, Sliding Window, Leaky Bucket, and Token Bucket

The article introduces the fixed‑window counter algorithm, which increments a counter for each request within a time period and triggers throttling when a predefined limit is reached; the counter resets at the start of the next period. It notes that this method can be easily implemented in both single‑node and distributed environments using Redis's atomic INCR operation.

It then discusses a major drawback of the fixed‑window approach: the critical‑window problem, where bursts of traffic at the boundary of two periods can exceed the server’s capacity even though each individual period stays within the limit.

Next, the sliding‑window algorithm is presented. The time window is divided into multiple smaller sub‑windows, each tracking its own request count. As time advances, expired sub‑windows are discarded, providing a smoother and more accurate throttling behavior that resolves the critical‑window issue.

The leaky‑bucket algorithm is described next. Incoming requests are placed into a bucket; if the bucket is full, excess requests are dropped. The bucket drains at a constant rate, ensuring a steady flow of allowed requests.

Finally, the token‑bucket algorithm is explained. Tokens are added to a bucket at a fixed rate (r = period/limit). When a request arrives, it consumes a token; if no token is available, the request is throttled. This method combines burst tolerance with a controlled average rate.

A comparative diagram summarizes the characteristics of all four algorithms, helping readers choose the most suitable method for their specific rate‑limiting needs.