iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Fixed-window rate limiters fail when their abrupt counter reset lets a caller spend the full quota on both sides of a boundary. That can admit nearly twice the configured allowance in a very short interval. The fix is not always to discard fixed windows: choose a limiter whose burst policy matches the service, then make its state shared and its admission decision atomic when the limit must span multiple servers.
Why do fixed-window rate limiters fail?
A fixed-window counter divides time into discrete, non-overlapping intervals and resets at each boundary. Let the limit be L requests per W seconds. Because each interval has its own counter, a caller can use L requests at the end of one interval and another L immediately after the next begins. The algorithm can therefore admit up to 2L requests in an arbitrarily short period around the boundary, despite a stated limit of L per W seconds. Redis describes this as a 2× boundary burst (Redis rate-limiter overview; Redis algorithm comparison).
For illustration—not a benchmark or a claim about a particular service—consider 100 requests per minute:
12:00:00 12:01:00 12:02:00
|--------------------------------|--------------------------------|
100 requests → | ← 100 requests
window reset
Potentially 200 requests pass in a very short interval around 12:01.The problem is the discontinuity between adjacent buckets. Moving the reset time, or anchoring each window to a caller’s first request, moves where the discontinuity occurs; it does not remove it while the policy still counts separate, non-overlapping buckets.
#1 Best Overall
- API Design Patterns
- ABIS BOOK
- Manning Publications
Which rate-limiting algorithm fits the policy?
Choose based on four things: whether you need an exact rolling cap or a smoothed allowance, how much state you can afford, whether bursts are acceptable, and whether excess traffic should be rejected or queued. Redis’s comparison describes these trade-offs as algorithm properties, not a claim that one design is best for every service (overview; comparison).
| Algorithm | Boundary and burst behavior | State and accuracy | Good fit |
|---|---|---|---|
| Fixed-window counter | An abrupt reset can allow a 2× burst across adjacent boundaries. | One counter; approximate for a rolling-window policy. | Simple quotas where boundary bursts are acceptable. |
| Sliding-window log | Counts timestamps within the rolling interval, avoiding the fixed-window boundary burst in the algorithmic model. | Exact rolling count; stores request timestamps, with state proportional to requests in the window, O(n). | High-value limits where exact rolling enforcement justifies the state cost. |
| Sliding-window counter | Combines counts from adjacent windows to smooth the boundary. | Near-exact rolling estimate using two counters, with less state than storing every timestamp. | General-purpose limits that need a practical balance of accuracy and state. |
| Token bucket | Allows controlled bursts up to the configured capacity as tokens replenish over time. | Bucket state; the policy must define refill rate and capacity. | APIs that allow bursts while enforcing a sustained rate. |
| Leaky bucket | Can reject bursts (policing) or smooth output by queuing traffic (shaping). | Bucket state; choose whether to police or queue and shape. | Strict no-burst enforcement or smoothed downstream traffic. |
How do you fix the burst at the window boundary?
1. Define the limit you actually want
Decide whether the requirement is a strict maximum over every rolling interval, a smoothed average, or a sustained rate that deliberately tolerates a burst. If a brief surge would overload an expensive endpoint, a fixed counter alone does not express a strict rolling cap. Use a sliding-window log when exactness is worth the timestamp storage, a sliding-window counter when a lower-state approximation is acceptable, or a token bucket when the burst is part of the intended policy.
Rank #2
2. Make time and boundaries consistent
For fixed windows, define alignment (such as epoch-aligned or first-request-anchored), what happens at the exact boundary, and how counter expiration relates to the key’s lifetime. For rolling algorithms, define a consistent clock and time units. Redis’s time-based Lua example obtains the current time inside the script using Redis server time, rather than relying on application instances to supply potentially inconsistent timestamps (Redis implementation documentation).
3. Make admission and update atomic
A separate check followed by an increment is unsafe under concurrency: several requests can all observe remaining quota before any updates the counter. The admission decision and state change must behave as one indivisible operation for the relevant key. Redis documents Lua scripting with EVAL as a way to perform the read, decision, and update atomically (Redis rate-limiter documentation).
4. Share state at the intended scope
A process-local counter enforces a per-process quota. If the same caller can reach multiple service instances, each independent counter can admit traffic, multiplying the effective allowance. Use shared state when the limit is meant to span instances, and specify whether it applies per user, IP address, API key, tenant, model, route, or globally. Redis describes centralized counters for these kinds of shared quotas (Redis rate-limiter documentation).
5. Tell clients when to try again
Return a clear rejection when a request exceeds the limit and, if the service supports it, a retry delay. Cloudflare documents Ratelimit and Ratelimit-Policy headers for quota and reset information, as well as retry-after when a limit is exceeded. These are Cloudflare API behaviors, not universal header guarantees; check the semantics implemented by the service clients are calling (Cloudflare API rate limits).
Rank #4
What changes in a distributed deployment?
Shared storage can coordinate counters across application instances, but “shared” still depends on the system’s actual scope. For example, Cloudflare says its request-rate counters use configured characteristic combinations and are not shared across all data centers, except for data centers in the same geographic location. An edge counter should not be assumed to represent a global counter (Cloudflare request-rate documentation).
Recommended Free Tools
Provider limits are also specific to a service and can change. Cloudflare’s API documentation, last updated August 25, 2026, lists a global limit of 1,200 requests per five-minute period per user; it says exceeding that limit blocks API calls for the next five minutes with HTTP 429. Treat that as Cloudflare’s documented policy on that date, not a general rate-limit standard (Cloudflare API rate limits).
Quick Recap
Best Value
Implementation checklist
- Write down the quota, interval, identity key, route or service scope, and whether the policy is rolling, fixed, or burst-tolerant.
- Select an algorithm whose boundary behavior matches the policy; do not expect a reset-time adjustment to eliminate fixed-window bursts.
- Define clock source, units, window alignment, exact-boundary behavior, and expiration rules.
- Keep the admission decision and state update atomic for each limit key.
- Confirm the counter is shared across every instance that must enforce the same quota, and verify geographic or regional scope where relevant.
- Return a clear limit response and document any retry headers or delays clients can rely on.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
