Practical rate limiting patterns for ASP.NET Core APIs

Public-facing APIs hosted in Australian data centres often experience sharp traffic spikes between 9am and 11am AEST, when Sydney and Melbourne offices start their day and queued batch jobs finally fire off accumulated requests. A well-tuned rate limiter keeps these bursts from overwhelming downstream services, throttles abusive clients, and gives backend teams predictable load. For organisations bound by the Privacy Act 1988, predictable throughput also reduces the chance of cascading failures that could trigger a notifiable data breach.

Rate limiting sits at the edge of an ASP.NET Core pipeline, where each incoming request is evaluated against a policy before any expensive work begins. Since .NET 7, the framework ships with a Microsoft.AspNetCore.RateLimiting middleware that supports several algorithms out of the box. This removes the historical need to pull in third-party libraries such as AspNetCoreRateLimit and keeps configuration declarative.

Australian developers working on fintech APIs in Brisbane or government portals in Canberra frequently need to combine rate limits with strong authentication and audit logging. The Australian Cyber Security Centre's Essential Eight guidance recommends rate limiting as a mitigation against brute-force and denial-of-service attempts, which makes the feature a practical checkbox for security accreditation. When the limiter rejects a request, the platform also needs a graceful response path that integrates cleanly with OpenTelemetry traces and existing Application Insights dashboards.

This article walks through choosing an algorithm, wiring the middleware into a typical Program.cs, partitioning limits per tenant, returning standards-compliant 429 responses, and finally observing the limiter in production. Code samples target .NET 8 and assume a hosted service running on Linux behind a reverse proxy, which is the common pattern for workloads deployed in Sydney or Perth regions of Azure.

Understanding rate limiting algorithms

The RateLimiter abstraction in ASP.NET Core supports four algorithms, each with different trade-offs around memory usage, fairness, and burst handling. Picking the right one is the foundation of a robust policy, because misconfigured limits either block legitimate traffic or fail to protect the backend during incidents.

A fixed window counter allows N requests per window of T seconds, resetting at the boundary. It is the cheapest to implement but suffers from boundary effects: a client can send N requests at second 59 and another N at second 60, effectively doubling the limit across two seconds. For low-stakes public endpoints in regional SaaS products, the simplicity often wins.

A sliding window refines the fixed approach by tracking the previous window's count and weighting it against the current window. Memory grows with the window size, but the boundary spike disappears. Token bucket replenishes tokens at a steady rate and allows controlled bursts up to the bucket capacity, which fits well for APIs serving a mix of human users and scheduled bots. Concurrency limiting caps the number of in-flight requests rather than the request rate, ideal for protecting a slow downstream like a SQL Server pool or an Azure SQL elastic database in Australia East.

For most Australian SaaS products, a combination works best: a token bucket on authentication endpoints to absorb login storms, and a sliding window on per-user API keys to enforce monthly quotas.

Configuring the built-in middleware in Program.cs

The middleware lives in the Microsoft.AspNetCore.RateLimiting namespace and is registered through builder.Services.AddRateLimiter(...). A typical setup uses the named policy pattern, which lets different controllers or minimal API groups opt into different limits using [EnableRateLimiting("policyName")] or RequireRateLimiting.

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    options.OnRejected = async (context, token) =>
    {
        context.HttpContext.Response.Headers.RetryAfter =
            ((int)context.Lease.TryGetMetadata(MetadataName.RetryAfter)
                 ?.TotalSeconds ?? 1).ToString();
        await context.HttpContext.Response.WriteAsJsonAsync(new
        {
            error = "rate_limited",
            message = "Too many requests, slow down."
        }, token);
    };

    options.AddPolicy("per-user", httpContext =>
    {
        var userId = httpContext.User.Identity?.Name ?? "anonymous";
        return RateLimitPartition.GetTokenBucketLimiter(userId, _ => new TokenBucketRateLimiterOptions
        {
            TokenLimit = 60,
            ReplenishmentPeriod = TimeSpan.FromMinutes(1),
            TokensPerPeriod = 30,
            QueueLimit = 0,
            AutoReplenishment = true
        });
    });
});

The call to app.UseRateLimiter() must come after UseAuthentication and UseAuthorization so the partition key can read the authenticated user. Placing it before authentication would force the limiter to key on IP address alone, which is awkward for users behind carrier-grade NAT on the NBN in regional areas such as Tamworth or Cairns. The policy is then applied per endpoint with .RequireRateLimiting("per-user") inside a MapGet or MapPost chain.

Partitioning limits per client and endpoint

Partitioning is what turns a single global cap into a fair per-tenant or per-IP policy. The RateLimitPartition factory exposes keyed limiters, and the key is computed from the incoming HttpContext. Common keys include the authenticated subject, an API key header, an Azure AD app registration, or the remote IP address with httpContext.Connection.RemoteIpAddress.

For B2B APIs sold to Australian retailers, partitioning by API key is the standard contract. A starter plan might get 60 requests per minute while an enterprise SKU gets 600. The same pattern works for the federal government's data.gov.au style portals, where each agency receives its own quota. When the limiter is keyed on IP, developers in shared office spaces such as Sydney's WeWork buildings need to be careful: a noisy neighbour can exhaust the IP's quota and starve the rest of the floor.

Endpoint-specific limits are useful for expensive operations. A POST /reports endpoint that runs an Azure Synapse query in Australia Southeast might warrant a tighter concurrency limit than a GET /health probe. Combining endpoint and client partitions is straightforward by composing policies or applying the [EnableRateLimiting] attribute at the action level, while a global policy covers the rest of the surface.

Responding with 429 and Retry-After headers

A rejected request should never look like a server crash. The HTTP standard reserves 429 Too Many Requests for this scenario and recommends a Retry-After header in seconds or as an HTTP-date. Clients built on HttpClient in .NET 8 respect this header automatically when used with Polly's retry strategy, which simplifies resilience on both ends.

Beyond the header, returning a structured JSON body with an error code and a human-readable message helps integrators diagnose the problem. Logging the rejection at warning level with the partition key, the rejected policy name, and the lease metadata produces a trail that supports the Office of the Australian Information Commissioner's expectations around reasonable technical safeguards. Some teams in Melbourne and Adelaide go further and emit a custom metric for rate_limit_rejections_total keyed by tenant, which feeds straight into an Azure Monitor alert when the rate climbs during an incident.

For partner integrations written in older .NET Framework, a plain text body remains a safer fallback. The OnRejected callback shown earlier lets the response be tailored per policy, so anonymous traffic can receive a minimal response while authenticated clients get richer details.

Observability and tuning in production

Limits that work on a developer's laptop rarely survive contact with real traffic. Once the middleware is live, three signals guide tuning: the 429 rejection rate per partition, the queue length of the token bucket, and p95 latency of the protected endpoint. Each is exposed through RateLimiter statistics and can be wired into OpenTelemetry using a custom Meter.

Application Insights in the Australia East region captures these metrics alongside dependency calls, which makes it easy to correlate a spike in rejections with a slow Cosmos DB query. When tuning, raising the TokenLimit is rarely the right first move; instead, look at whether the partition key is too coarse. If every authenticated user shares a single bucket because the NameIdentifier claim is missing, the policy degrades to a global cap and legitimate users get blocked. Adding structured logging for httpContext.User.Identity.IsAuthenticated at the partition factory surfaces this during a post-incident review.

Finally, write a load test in k6 or NBomber that targets the Australian endpoints from a region close to Australia Central to verify behaviour under realistic latency. A limit that looks generous locally may still be too tight when round-trip time pushes requests into the next replenishment window. Adjusting the policy, redeploying, and comparing the next day's dashboard closes the loop and keeps the API fair for everyone from a solo founder in Hobart to a national retailer's integration team in Parramatta. A streaming workload like building a media streaming app with .NET Core and Azure Media Services can apply the same patterns to protect its ingest endpoints from encoder bursts.