ASP.NET Core Rate Limiting with NCache
NCache RateLimiting integration provides distributed rate limiters for ASP.NET Core applications through the standard ASP.NET Core Rate Limiting middleware. It lets applications use NCache as the shared state store for rate limiter policies, so request limits can be coordinated across multiple application instances, servers, or containers.
The integration plugs into Microsoft.AspNetCore.RateLimiting and provides NCache-backed implementations for the following limiter types:
- Concurrency Rate Limiter
- Fixed Window Rate Limiter
- Token Bucket Rate Limiter
- Sliding Window Rate Limiter
Note
This integration is provided through the NCache.OSS.RateLimiting package.
Important
NCache RateLimiting policies are partitioned by policy name only. Every request matching the same policy resolves to the same fixed partition. The current implementation does not provide per-client, per-IP, or per-request partitioning out of the box.
Why Use ASP.NET Core Rate Limiting with NCache?
ASP.NET Core Rate Limiting controls how many requests are allowed to access application endpoints within a defined limit. In a single-server deployment, rate limit state can be maintained locally. However, in a load-balanced or distributed deployment, each application instance must coordinate with the others to enforce limits consistently.
NCache acts as the shared coordination point for rate limiter state. This allows all application instances using the same NCache cache and policy configuration to evaluate limits against common distributed state instead of maintaining independent local counters.
Using NCache for rate limiting is useful when:
- Multiple application instances serve the same protected endpoints.
- Rate limiter state must be shared across servers.
- Request limits must remain consistent in load-balanced environments.
- Application nodes need distributed permit, token, or window tracking.
- In-memory local counters are not sufficient for cluster-wide enforcement.
How Rate Limiting Works with NCache
NCache RateLimiting integrates with the ASP.NET Core Rate Limiting middleware through policy registration methods such as AddNCacheConcurrencyLimiter, AddNCacheFixedWindowLimiter, AddNCacheTokenBucketLimiter, and AddNCacheSlidingWindowLimiter.
When a request reaches an endpoint protected by a rate limiting policy, the ASP.NET Core middleware resolves the configured policy. The NCache integration then resolves the fixed partition for that policy name and evaluates the request against the distributed state stored in NCache.
The general flow is:
- An incoming request reaches the ASP.NET Core Rate Limiting middleware.
- The middleware matches the configured policy name.
- The policy resolves to the same fixed partition for every request using that policy.
- The NCache-backed limiter reads and updates shared limiter state in NCache.
- The request is either granted a lease or rejected based on the configured limit.
For distributed coordination, the implementation uses a custom NCache-backed lock mechanism based on atomic add-if-absent semantics. This is not the same as NCache's built-in pessimistic locking feature.
Supported Limiter Types
NCache supports the following limiter types:
Concurrency Rate Limiter
The Concurrency Rate Limiter limits the number of concurrent in-flight requests for a policy. When the permit limit is reached, additional requests can be queued up to the configured queue limit. This is the only limiter type in this integration that supports queueing.
Fixed Window Rate Limiter
The Fixed Window Rate Limiter allows a fixed number of requests during a configured time window. Once the window expires, the request count resets. Requests over the limit are rejected immediately.
Token Bucket Rate Limiter
The Token Bucket Rate Limiter maintains a bucket of available tokens. Tokens are replenished at a configured interval, and each accepted request consumes a token. This allows short bursts while still enforcing a long-term request rate.
Sliding Window Rate Limiter
The Sliding Window Rate Limiter evaluates requests against a trailing time interval. This implementation uses a sliding log model and counts accepted request timestamps within the trailing window for each new request. Requests are rejected once the trailing count reaches the configured permit limit.
Policy Partitioning
Each NCache rate limiter policy uses a fixed partition based on the policy name. The HttpContext passed into the ASP.NET Core policy callback is not inspected to derive a client-specific or request-specific key.
For example, all requests that match fixedWindowPolicy use the same distributed limiter state for that policy. If you need per-client or per-IP limiting, the current package does not provide that behavior out of the box.
Limiter Construction
The RateLimiter for a policy partition is constructed lazily on first use. This includes the underlying NCache connection. Under concurrent load immediately after a cold start, the first request may pay the initialization cost while other requests wait behind it.
If this behavior matters for a deployment, warm up the policy at application startup, for example through an IHostedService, instead of allowing the first production request to initialize the limiter.
In This Section
NCache as RateLimiting Provider
Explains how to configure NCache-backed ASP.NET Core rate limiter policies using code-based configuration or appsettings.json.