Rate Limiting in ASP.NET Core: Four Algorithms Compared
A guide to the four built-in rate limiting algorithms in ASP.NET Core: fixed window, sliding window, token bucket and concurrency limiter. It shows how each one behaves under the same traffic and when to pick it for a given endpoint. Useful for any .NET developer who needs to protect an API from abusive or buggy clients.
Key points
- Register policies with AddRateLimiter and place UseRateLimiter after UseAuthentication and UseAuthorization so user claims are available to the limiter.
- Fixed window suits cheap endpoints like login, but requests can double up around the window boundary.
- Sliding window uses SegmentsPerWindow to smooth the boundary; six to ten segments is a sensible range.
- Token bucket combines TokenLimit and TokensPerPeriod to allow short bursts while keeping an average rate.
- Concurrency limiter caps in-flight requests with PermitLimit and suits slow report or export endpoints.
- The AddFixedWindowLimiter helper shares one counter across all callers, so use partitioning for per-client limits.
Rate limiting caps how much work a single caller can trigger within a given time. It guards against abuse, runaway retry loops and one client starving everyone else. Since .NET 7 the feature ships with ASP.NET Core: the algorithms live in System.Threading.RateLimiting and the middleware in Microsoft.AspNetCore.RateLimiting, so no extra NuGet package is needed.
The author walks through four algorithms with analogies and code. A fixed window resets a counter on a schedule, which lets a client double its allowance across a boundary. A sliding window splits the period into segments to smooth that out. A token bucket separates the sustained rate from the burst size. A concurrency limiter counts requests in flight instead of requests per minute. The post also covers choosing between them and partitioning limits per IP, user or API key. Check the original for the full configuration examples.
Real-world use
- Protecting login and password reset endpoints from brute-force attempts with a fixed window.
- Enforcing exactly N requests per minute on a public product catalog API using a sliding window.
- A multi-tenant SaaS API that gives free and paid plans different bucket sizes and refill rates.
- Limiting concurrent CSV or PDF generation and AI model calls so heavy endpoints do not exhaust memory or CPU.
Why it matters
Choosing the algorithm per endpoint protects your database and thread pool from a single misbehaving client. Setting up policies and partitioning correctly from the start avoids false 429 responses later.