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

NCache Rate Limiting is available through the following packages:

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 identifies the policy applied to the endpoint.
  • The policy resolves the same fixed partition for every request using that policy.
  • The NCache-backed limiter reads and updates the shared state in NCache.
  • If a permit is available, the request receives an acquired lease and proceeds.
  • If no permit is available, the Concurrency Rate Limiter may queue the request; other limiter types reject it immediately.

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. Queued requests are released in arrival order as permits become available. 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 up to the configured token limit, and each accepted request consumes one token. This allows short bursts while still enforcing a long-term request rate. If no tokens are available, the request is rejected immediately; this limiter does not queue requests.

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.