Rate limiting middleware for resilient ASP.NET Core APIs

Rate limiting controls how much traffic an API accepts over time. Creating a rate limiting middleware in ASP.NET Core prevents a sudden flood of requests from exhausting database connections, triggering excessive downstream charges, or turning a manageable spike into a full outage.

Effective protection depends on more than choosing a fixed requests-per-second value. The middleware needs explicit policies, fair caller identification, consistent counters across application instances, and clear responses that tell clients when to slow down.

Why uncontrolled traffic breaks APIs

Imagine a product catalogue endpoint receiving normal morning traffic, followed by a crawler that requests every item as quickly as possible. Without a limit, each request can open a database connection and occupy a worker thread. Response times rise, healthy users encounter errors, and recovery becomes harder as the backlog grows.

A rate limiter acts as a controlled entry point. It distinguishes legitimate usage from bursts that exceed an agreed budget, protecting both the API and its dependencies. It also provides a predictable mechanism for handling traffic during launches, promotions, billing cycles, or accidental retry loops.

This API discipline belongs alongside the cloud, DevOps and data sessions at the C# Corner Annual Conference, where developers can examine platform decisions alongside the operational constraints of production services.

Designing policies that match actual demand

Group endpoints by their cost and usage pattern. Read-only catalogue requests can usually tolerate more traffic than an export that runs an expensive report. Authentication and password-reset endpoints often need tighter controls because repeated attempts can indicate credential abuse. A single global limit for every route is simpler, but it can unnecessarily restrict low-risk operations.

Choose an algorithm that reflects the intended behaviour. A fixed window provides a simple quota but permits a burst around each window boundary. A sliding window spreads limits across time. A token bucket allows controlled bursts while enforcing an average rate, and a concurrency limiter directly controls how many operations may run simultaneously.

Set initial thresholds from measured traffic, not intuition alone. Observe normal traffic during Australian business hours, including an arvo release when teams across Melbourne and Sydney might begin broad testing. Then add enough headroom for genuine demand. Review the limits when customer patterns change, since a quota that suited a small pilot may be wasteful for a national product.

Building the middleware into the request pipeline

Register the middleware after routing so it can inspect the selected endpoint. When policies depend on authenticated users, place it after authentication; otherwise, the available identity may be incomplete. Middleware order matters because an early rejection should avoid work that the caller was never authorised to request.

Separate policy evaluation from counter storage through an interface such as IRateLimitStore. The store acquires capacity and returns an allowed flag, any remaining quota, and a retry delay when appropriate. A compact version of the middleware can then remain focused on the HTTP request and response:

public sealed class RateLimitMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IRateLimitStore _store;

    public RateLimitMiddleware(RequestDelegate next, IRateLimitStore store)
    {
        _next = next;
        _store = store;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var key = context.Request.Path.Value ?? "/";
        var decision = await _store.TryAcquireAsync(
            key, context.RequestAborted);

        if (!decision.Allowed)
        {
            context.Response.StatusCode = StatusCodes.Status429TooManyRequests;
            context.Response.Headers.RetryAfter =
                decision.RetryAfterSeconds.ToString();

            await context.Response.WriteAsJsonAsync(
                new { error = "Too many requests." },
                context.RequestAborted);
            return;
        }

        await _next(context);
    }
}

The path-only key is deliberately simple. A multi-tenant application would normally incorporate a tenant identifier, account, or authorised user before calling the store. That key construction must be deterministic and resistant to attackers creating unlimited identities.

Return HTTP 429 for a rejected request and include Retry-After when the server can estimate the wait. Keep the response body consistent, and avoid exposing internal quota details that reveal other customers’ activity. The store must perform atomic acquisition; a read followed by an unchecked increment can over-admit requests under concurrent load.

Keeping counters consistent across multiple instances

An in-memory counter is fast, but each application instance maintains a separate allowance. A service running on four servers can therefore accept roughly four times the intended traffic. This becomes particularly noticeable during autoscaling, when a traffic surge creates additional instances and silently expands the limit.

Use a shared store such as Redis when limits must apply across the service. Atomic scripts or equivalent server-side operations can update counters safely, while expiry prevents abandoned keys from consuming memory indefinitely. The latency and operational cost of that store must remain acceptable for the endpoint’s traffic.

For teams in Sydney, Melbourne, Brisbane or Perth, place regional infrastructure close to the application while checking contractual and data-residency requirements. Azure Australia East and Australia Southeast are common regional choices for Australian workloads, but users in Perth can still experience additional round-trip time against east-coast services. Budget Redis and related resources in Australian dollars, remembering that GST generally applies to taxable business purchases.

Decide how the service behaves if the shared store becomes unavailable. A public read endpoint may fail open and continue serving cached data, while an expensive report might fail closed. Apply that decision per policy rather than placing one global fallback over every route.

Identifying callers without penalising the wrong people

A fair limit needs a stable caller identity. For business users, a tenant or account identifier is usually more meaningful than an IP address. For service-to-service traffic, use the authenticated client identifier. Anonymous callers may require an IP-based partition, ideally combined with a coarse route category to prevent one address from consuming another endpoint’s allowance.

Do not trust identity values that have not been validated by the authentication pipeline. Middleware ordering becomes critical here: a user identifier is empty when authentication runs later, while claims copied directly from an untrusted header could let callers manufacture fresh identities. Resolve identity from the server’s authenticated principal or trusted endpoint metadata.

IP addresses also need careful interpretation. Many Australian households connect through the NBN, and some addresses change when their connection is reallocated. Mobile networks commonly use carrier-grade NAT, placing numerous unrelated customers behind one public address. A strict per-address limit can therefore block a university, corporate office, or mobile carrier customer collectively. Use appropriate prefixes, supplement IP identity with authenticated context, and ensure clients can request a legitimate increase.

Comparing the main enforcement approaches

Modern ASP.NET Core includes built-in rate limiting policies for fixed windows, token buckets, and concurrency. Named policies can partition requests by endpoint, IP address, or authenticated user. This is often the best starting point, although the default rejection callback must be configured to return the intended status rather than assuming every rejection automatically produces a 429 response.

A custom middleware remains useful when quotas depend on subscription tiers, weighted operations, multiple resources, or a business-specific retry calculation. An API gateway provides broader protection across an estate, while a service mesh can apply consistent limits between services. These layers operate at different boundaries, so their responsibilities should not overlap unintentionally.

The practical choice depends on where the authoritative quota belongs. Standard platform policies suit consistent service-wide rules, while custom application logic suits entitlements and resource consumption. A gateway can remain the coarse outer boundary as the application applies finer-grained limits.

Rolling out safely and proving the behaviour

Introduce enforcement in stages. Begin by calculating decisions without rejecting requests, allowing teams to compare projected limits with actual traffic. Then apply a generous threshold to a low-risk endpoint, followed by stricter policies for authentication, exports, or high-cost operations. Keep each change observable and reversible.

Exercise normal traffic, deliberate bursts, concurrent requests, expired counters, and failures of the backing store. Confirm that legitimate clients receive 429 responses with useful retry guidance, while permitted requests continue without added latency. Track rejection counts, acquisition time, store errors, and the distribution of active keys; excessive key cardinality can itself become a performance problem.

The finished limiter should enforce the same budget across every instance, distinguish callers fairly, and fail in a deliberate manner when its dependencies are impaired. A predictable API protects its downstream systems while giving legitimate clients a clear path to the resources they need.