Sliding Window Counter Rate Limiting

Introduction

Sliding Window Counter is a practical rate limiting algorithm used to control how many requests a user, IP address, API key, or endpoint can make within a time period.

It improves on Fixed Window Counter by reducing sudden bursts near window boundaries. At the same time, it avoids the heavy memory usage of Sliding Window Log, which stores timestamps for every accepted request.

Why Sliding Window Counter Is Needed

Fixed Window Counter is simple, but it has a boundary burst problem. If the limit is 100 requests per minute, a user may send 100 requests at the end of one minute and another 100 at the start of the next minute.

Technically, both windows follow the rule. But practically, the system may receive 200 requests in a very short time.

Sliding Window Log solves this by storing every request timestamp and checking the exact last window. However, storing timestamps for every request becomes expensive at high traffic.

Sliding Window Counter provides a balance:

• Better than Fixed Window Counter: It reduces sudden double bursts.

• Lighter than Sliding Window Log: It does not store every request timestamp.

• Practical for APIs: It gives good enough accuracy with low memory usage.

Basic Idea of Sliding Window Counter

Sliding Window Counter uses two counters:

• Previous window counter: Count of requests in the previous fixed window.

• Current window counter: Count of requests in the current fixed window.

Instead of completely ignoring the previous window after a reset, the algorithm takes a weighted portion of it. The weight depends on how far we are into the current window.

The general formula is:

Estimated Count = Current Window Count + (Previous Window Count x Remaining Fraction of Previous Window)

If the estimated count is below the limit, the request is allowed. If the estimated count reaches the limit, the request is rejected.

How the Algorithm Works

A simple request flow looks like this: Request arrives => Calculate estimated count => Compare with limit => Allow or reject

The algorithm usually follows these steps:

• Select window size: Choose a fixed duration such as 1 minute, 1 hour, or any configured time period.

• Define limit: Decide the allowed number of requests, such as 100 requests per user per minute.

• Track counters: Maintain the current window count and previous window count.

• Calculate weight: Decide how much of the previous window still overlaps with the current sliding interval.

• Estimate total requests: Add the current count and weighted previous count.

• Make decision: Allow the request if the estimate is below the limit; otherwise reject it.

Rejected requests are commonly returned with: HTTP 429 Too Many Requests

Comparison With Other Algorithms

Sliding Window Counter sits between Fixed Window Counter and Sliding Window Log. It is more accurate than Fixed Window Counter but less memory-heavy than Sliding Window Log.

This is why Sliding Window Counter is often preferred when a system needs smoother rate limiting without storing every request timestamp.

Advantages and Limitations

Sliding Window Counter is useful because it gives a clean tradeoff between fairness, accuracy, and efficiency.

• Low memory usage: It stores counters instead of every timestamp.

• Smooth traffic control: It reduces sudden spikes at window boundaries.

• Fast decision-making: The request check is simple and efficient.

• Scalable behavior: It works better for high-traffic APIs than timestamp-heavy logs.

• Approximate result: It is not perfectly accurate because it estimates previous window contribution.

• More complex than fixed window: It needs weighted calculation instead of a simple counter reset.

For most practical systems, this approximation is acceptable because the algorithm prevents major abuse while keeping resource usage low.

Summary

Sliding Window Counter is a rate limiting algorithm that estimates request count using the current window and a weighted portion of the previous window. This helps reduce the double burst problem found in Fixed Window Counter.

It is less exact than Sliding Window Log, but it uses much less memory because it does not store every request timestamp. This makes it a strong practical choice for API rate limiting, request throttling, abuse prevention, and scalable backend protection.