Skip to main content

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.

The FixedWindowPolicy is one of the four in-memory rate-limiting policies registered in Dotnet-RateLimiter via ASP.NET Core’s built-in AddRateLimiter infrastructure. It uses a simple counter that resets at the end of each fixed time window. Because the counter lives in process memory, this policy is ideal for single-node deployments, local development, and integration testing — situations where distributed consistency across multiple application instances is not a requirement.

​
Registration

The policy is registered inside AddCustomRateLimiter in RateLimiterExtensions.cs: 
options.AddFixedWindowLimiter("FixedWindowPolicy", opt =>
{
    opt.Window = TimeSpan.FromSeconds(5);
    opt.PermitLimit = 5;
    opt.QueueLimit = 10;
    opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
}).RejectionStatusCode = 429;
OptionValueMeaning
Window5 secondsDuration of each fixed time window
PermitLimit5Maximum requests allowed per window
QueueLimit10Maximum requests that can wait in the queue beyond the limit
QueueProcessingOrderOldestFirstQueued requests are processed in first-in, first-out order
RejectionStatusCode429HTTP status returned when both the limit and queue are full

​
Applying the Policy

Decorate any controller action with [EnableRateLimiting("FixedWindowPolicy")] to opt that endpoint into the policy. From TestController.cs: 
[HttpGet("fixedwindow"), EnableRateLimiting("FixedWindowPolicy")]
public IEnumerable<WeatherForecast> TestFixedWindow() =>
    Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
The attribute name must match the policy name string used during registration ("FixedWindowPolicy").

​
How the Queue Works

When the number of active requests reaches PermitLimit (5), additional requests are not immediately rejected — they are held in a queue up to QueueLimit (10). 
Requests 1–5  → Permitted immediately
Requests 6–15 → Queued (OldestFirst), released when the window resets
Request 16+   → Rejected with HTTP 429
With QueueProcessingOrder.OldestFirst, the request that has been waiting the longest is the first to be released when capacity becomes available at the start of the next window. This prevents newer requests from jumping ahead of older ones, which is the fairest behaviour for most REST APIs.

​
When to Use

ScenarioRecommendation
Single-node application or local development✅ FixedWindowPolicy is appropriate
Unit/integration tests that need rate limiting✅ No Redis dependency required
Kubernetes or multi-replica cloud deployment❌ Use the Redis Fixed Window instead
Need smoother request distribution over timeConsider SlidingWindowPolicy
Not suitable for distributed deployments. The FixedWindowPolicy stores its counter in the memory of a single process. If your application runs on more than one instance (e.g., multiple Kubernetes pods, a load-balanced cluster), each instance maintains its own independent counter. A caller routed to different instances on consecutive requests can therefore exceed the intended limit. For distributed rate limiting, use the Redis Fixed Window strategy, which enforces a single shared counter across all instances via Redis.

Build docs developers (and LLMs) love

Get started for freeTalk to us