The SlidingWindowPolicy improves on the standard fixed window by subdividing the time window into smaller segments. Rather than resetting the entire permit counter at a single hard boundary, it reclaims slots segment by segment as time advances. The result is a rolling, continuously-evaluated window that smooths out bursty traffic and prevents the double-burst problem that affects fixed window strategies at their reset boundaries.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/nimanikoo/Dotnet-RateLimiter/llms.txt
Use this file to discover all available pages before exploring further.
How Segments Work
TheSegmentsPerWindow option divides the total window into equal sub-windows. The rate limiter tracks how many requests were made in each segment and slides the window forward one segment at a time. As the oldest segment falls out of the window, its permits are reclaimed and become available for new requests.
PermitLimit over any rolling 10-second period, not just within aligned clock boundaries.
Registration
The policy is registered insideAddCustomRateLimiter in RateLimiterExtensions.cs:
| Option | Value | Meaning |
|---|---|---|
Window | 10 seconds | Total duration of the rolling window |
PermitLimit | 5 | Maximum requests allowed within any rolling window period |
QueueLimit | 10 | Maximum requests that can wait beyond the permit limit |
QueueProcessingOrder | OldestFirst | Oldest waiting requests are released first when permits free up |
SegmentsPerWindow | 4 | Number of sub-windows; more segments = finer-grained sliding |
RejectionStatusCode | 429 | HTTP status returned when both the limit and queue are exhausted |
Segment Math
Applying the Policy
Decorate any controller action with[EnableRateLimiting("SlidingWindowPolicy")]. From TestController.cs:
When to Use
| Scenario | Recommendation |
|---|---|
| APIs where smooth traffic distribution matters | ✅ SlidingWindowPolicy is ideal |
| Webhook consumers or event-driven ingestion endpoints | ✅ Prevents segment-boundary spikes |
| Simple single-node apps where bursts are acceptable | FixedWindowPolicy may be simpler |
| Multi-instance / distributed deployments | Use Redis Fixed Window instead |
Fixed Window vs Sliding Window
- Fixed Window
- Sliding Window
How it resets: The counter resets all at once at the end of the window.Burst risk: A caller can fire Best for: Simple, lightweight throttling on single-node apps where boundary bursts are acceptable.
PermitLimit requests just before a reset and another PermitLimit requests just after — resulting in 2 × PermitLimit requests in a very short span.Configuration (FixedWindowPolicy):