Sliding Window Log Rate Limiting

Introduction

Sliding Window Log is a rate limiting algorithm used to control how many requests are allowed within a recent time period. It is commonly discussed after Fixed Window Counter because it solves one of fixed window’s biggest problems: sudden bursts near window boundaries.

Instead of resetting a counter at fixed intervals, Sliding Window Log looks backward from the current request time and counts only the requests that happened inside the latest window.

What Is Sliding Window Log?

Sliding Window Log maintains a log of timestamps for successfully processed requests. Whenever a new request arrives, the algorithm checks how many stored timestamps fall within the current sliding window.

For example, suppose the rule is: 100 requests per user per hour

When a request arrives at 2:30 PM, the algorithm checks how many requests that user made between 1:30 PM and 2:30 PM. If the count is below 100, the request is allowed. If the count has already reached 100, the request is rejected.

The window is not fixed like 1:00 PM to 2:00 PM. It moves with the current time, which makes the limit more accurate.

How Sliding Window Log Works

The algorithm follows a simple sequence:

• Choose a window size: The system defines a time range such as 1 minute, 1 hour, or 24 hours.

• Define a rate limit rule: The rule may be based on user, IP address, API key, endpoint, or a combination of these.

• Store request timestamps: Every accepted request stores its timestamp in a log.

• Remove old timestamps: Timestamps outside the current window are removed because they no longer matter.

• Count recent requests: The remaining timestamps represent requests made inside the current window.

• Allow or reject: If the count is below the limit, the request is accepted; otherwise, it is rejected.

A short flow looks like this: Request arrives => Old timestamps removed => Recent requests counted => Request allowed or rejected

If the request is rejected, systems commonly return: HTTP 429 Too Many Requests

Why It Solves Boundary Bursts

Fixed Window Counter resets at fixed boundaries. Because of this, a user may send many requests at the end of one window and many more at the beginning of the next window.

Sliding Window Log avoids this by checking the last N seconds, minutes, or hours from the current request time. The window continuously moves forward instead of resetting suddenly.

This accuracy is the main reason Sliding Window Log is useful for sensitive APIs where sudden request bursts should be controlled more strictly.

Rule Keys in Sliding Window Log

A rate limiter must decide whose requests are being counted. This is done using a rule key.

Common rule keys include:

• User ID: Useful for logged-in application users.

• IP address: Useful for public traffic and basic abuse protection.

• API key: Useful for developer platforms and customer-specific quotas.

• Endpoint: Useful for stricter limits on login, OTP, payment, or password reset APIs.

• Combined key: Useful when limits need more precision, such as user plus endpoint.

The algorithm remains the same. Only the key used for counting changes based on the system requirement.

Advantages and Drawback

Sliding Window Log gives accurate rate limiting because it counts requests in a real moving window, not in fixed blocks. This makes it good for preventing sudden boundary bursts and controlling API traffic more fairly.

Its main drawback is memory usage. Since every accepted request timestamp must be stored, memory consumption grows as traffic increases. For small limits, this is manageable. For very high request rates, storing millions of timestamps can become expensive.

Because of this, old timestamps should be removed regularly. Once a timestamp falls outside the current window, keeping it does not help the algorithm and only wastes memory.

Summary

Sliding Window Log is a rate limiting algorithm that stores timestamps of accepted requests and counts only those inside the latest moving time window. If the count is below the configured limit, the request is allowed. If the limit has already been reached, the request is rejected.

It is more accurate than Fixed Window Counter and avoids sudden boundary bursts. Its main limitation is higher memory usage, because each accepted request needs its own timestamp until it falls outside the active window.