Rate Limiting in ASP.NET Core: Design, Pitfalls, and Interview Answers

What Is Rate Limiting in ASP.NET Core?

Rate limiting in ASP.NET Core is one of the most practical API design topics for modern .NET developers because it protects APIs from abuse, controls traffic, improves reliability, and helps reduce cloud and AI service costs.

Rate limiting in ASP.NET Core is especially useful for public APIs, SaaS applications, AI-powered endpoints, and multi-tenant systems where traffic control matters.

Rate limiting is one of those topics that looks simple at first, but becomes very important when we design real production APIs.

When I first looked at rate limiting, I thought it was only about blocking too many requests. But in real ASP.NET Core applications, rate limiting is connected to security, performance, reliability, cloud cost, API fairness, and production stability.

In this article, I want to explain rate limiting in a practical way — how it works in ASP.NET Core, where to use it, what mistakes to avoid, and how to answer rate limiting questions in senior .NET interviews.

What Is Rate Limiting?

Rate limiting means controlling how many requests a client, user, IP address, API key, tenant, or application can make within a specific time or concurrency limit.

For example:

Allow 100 requests per user per minute.
Allow only 5 login attempts per IP per minute.
Allow only 2 concurrent report-generation requests per user.
Allow 20 AI summarization requests per tenant every 10 minutes.

In ASP.NET Core, we can define rate limiting policies globally or apply them to specific endpoints. This allows us to protect sensitive or expensive endpoints without applying the same rule everywhere.

Microsoft provides official documentation for ASP.NET Core rate limiting here: ASP.NET Core Rate Limiting Documentation.

Why Rate Limiting Matters in Real Projects

In a production system, rate limiting is useful for many reasons.

1. Preventing Abuse

Public APIs, login pages, search endpoints, and file upload endpoints can be abused by automated traffic. Rate limiting helps reduce brute-force attempts and automated misuse.

2. Protecting Backend Services

One noisy client should not overload SQL Server, Redis, Azure Service Bus, Azure OpenAI, Claude, Gemini, payment APIs, or any third-party service.

3. Improving Fairness

If many users share the same application, every user should get a fair chance to use the system. One user should not consume all available capacity.

4. Reducing Cloud and AI Cost

This is especially important for AI applications. If every request calls an LLM API, uncontrolled traffic can become expensive very quickly.

5. Improving Reliability

Rate limiting helps the application fail gracefully with 429 Too Many Requests instead of letting the API slow down, timeout, or crash under pressure.

When we design rate limiting in ASP.NET Core, we should choose the algorithm based on the endpoint cost, user behavior, and business risk.

Common Rate Limiting Algorithms

ASP.NET Core supports several rate limiting styles. Each one solves a different type of problem.

Fixed window, sliding window, and token bucket limit requests over time. The concurrency limiter is different because it limits only simultaneous requests.

Example 1: Basic Fixed Window Rate Limiting

Fixed window rate limiting allows a fixed number of requests in a specific time window.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddFixedWindowLimiter("fixed-api-policy", limiterOptions =>
    {
        limiterOptions.PermitLimit = 100;
        limiterOptions.Window = TimeSpan.FromMinutes(1);
        limiterOptions.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        limiterOptions.QueueLimit = 0;
    });
});

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/api/products", () =>
{
    return Results.Ok("Products returned successfully.");
})
.RequireRateLimiting("fixed-api-policy");

app.Run();

Explanation

In this example, the endpoint /api/products allows 100 requests per minute.

If the limit is exceeded, ASP.NET Core returns:

429 Too Many Requests

Fixed window rate limiting is simple and useful for public APIs, but it has one weakness. If the window resets every minute, a client may send many requests at the end of one minute and again at the beginning of the next minute. This can create a sudden burst.

Example 2: Sliding Window Rate Limiting

Sliding window rate limiting gives smoother traffic control than fixed window rate limiting.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddSlidingWindowLimiter("sliding-api-policy", limiterOptions =>
    {
        limiterOptions.PermitLimit = 100;
        limiterOptions.Window = TimeSpan.FromMinutes(1);
        limiterOptions.SegmentsPerWindow = 6;
        limiterOptions.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        limiterOptions.QueueLimit = 0;
    });
});

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/api/orders", () =>
{
    return Results.Ok("Orders returned successfully.");
})
.RequireRateLimiting("sliding-api-policy");

app.Run();

Explanation

This still allows 100 requests per minute, but the one-minute window is divided into smaller segments.

This means traffic is controlled more smoothly instead of resetting sharply at the end of each minute.

Sliding window is a good choice for APIs where we want more predictable traffic control.

Example 3: Token Bucket Rate Limiting

Token bucket rate limiting is useful when we want to allow short bursts but still control average usage.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddTokenBucketLimiter("token-api-policy", limiterOptions =>
    {
        limiterOptions.TokenLimit = 50;
        limiterOptions.TokensPerPeriod = 10;
        limiterOptions.ReplenishmentPeriod = TimeSpan.FromSeconds(10);
        limiterOptions.AutoReplenishment = true;
        limiterOptions.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        limiterOptions.QueueLimit = 0;
    });
});

var app = builder.Build();

app.UseRateLimiter();

app.MapPost("/api/ai/summarize", () =>
{
    return Results.Ok("Document summarized successfully.");
})
.RequireRateLimiting("token-api-policy");

app.Run();

Explanation

Think of this like a bucket with tokens.

Each request consumes a token. Tokens are added back over time. If the bucket is empty, the request is rejected.

Token bucket rate limiting is useful for endpoints like:

/api/ai/summarize
/api/payment/process
/api/search
/api/report/generate

For AI applications, token bucket rate limiting is very practical because it helps control expensive calls to services like Azure OpenAI, Claude, Gemini, or other AI APIs.

Example 4: Concurrency Limiter for Expensive Operations

A concurrency limiter is not about requests per minute. It controls how many requests can run at the same time.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddConcurrencyLimiter("report-policy", limiterOptions =>
    {
        limiterOptions.PermitLimit = 2;
        limiterOptions.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        limiterOptions.QueueLimit = 2;
    });
});

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/api/reports/monthly", async () =>
{
    await Task.Delay(3000);
    return Results.Ok("Monthly report generated.");
})
.RequireRateLimiting("report-policy");

app.Run();

Explanation

This allows only two report requests to execute at the same time.

This is very useful for:

Large reports
PDF generation
Excel exports
AI document processing
Long-running database queries
Third-party API calls

The concurrency limiter is different from fixed window, sliding window, and token bucket because it does not limit total requests over a time period. It only limits how many are running at the same time.

Example 5: Per-User Rate Limiting

In real applications, we usually do not want one global counter for everyone.

We often want limits by:

User ID
Tenant ID
API key
Client IP
Subscription plan
Organization ID

Here is an example using a partitioned limiter.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication();
builder.Services.AddAuthorization();

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddPolicy("per-user-policy", httpContext =>
    {
        var userName = httpContext.User.Identity?.Name;

        var partitionKey = !string.IsNullOrWhiteSpace(userName)
            ? userName
            : httpContext.Connection.RemoteIpAddress?.ToString() ?? "anonymous";

        return RateLimitPartition.GetSlidingWindowLimiter(
            partitionKey: partitionKey,
            factory: _ => new SlidingWindowRateLimiterOptions
            {
                PermitLimit = 100,
                Window = TimeSpan.FromMinutes(1),
                SegmentsPerWindow = 6,
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            });
    });
});

var app = builder.Build();

app.UseAuthentication();

// Important when the limiter depends on authenticated user information.
app.UseRateLimiter();

app.UseAuthorization();

app.MapGet("/api/profile", () =>
{
    return Results.Ok("User profile returned.");
})
.RequireRateLimiting("per-user-policy")
.RequireAuthorization();

app.Run();

Explanation

This example limits requests by authenticated user name.

If the user is not authenticated, it falls back to IP address or anonymous.

In a production application, I would usually prefer user ID, tenant ID, API key, or subscription plan instead of only IP address.

Returning a Better 429 Response

A good API should not just block the request. It should return a useful response.

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.OnRejected = async (context, cancellationToken) =>
    {
        context.HttpContext.Response.StatusCode =
            StatusCodes.Status429TooManyRequests;

        context.HttpContext.Response.ContentType = "application/json";

        await context.HttpContext.Response.WriteAsJsonAsync(new
        {
            error = "Too many requests",
            message = "Rate limit exceeded. Please try again later."
        }, cancellationToken);
    };
});

Why This Matters

This gives API consumers a clear error message.

For production APIs, we can also add:

Retry-After header
Correlation ID
Error code
API documentation link
Support message

Important Rate Limiting Pitfalls

Pitfall 1: Using Only IP-Based Rate Limiting

IP-based rate limiting is easy, but it can be risky.

In real production systems, many users may share the same IP address because of:

Corporate networks
Mobile networks
VPNs
NAT gateways
Proxy servers
Load balancers

If we rate limit only by IP, one heavy user may affect many valid users.

Better design:

Authenticated user ID
Tenant ID
API key
Subscription tier
Client application ID

Use IP only as a fallback for anonymous users.

Pitfall 2: Forgetting Reverse Proxy Headers

If an ASP.NET Core app runs behind Azure App Service, Azure Front Door, Application Gateway, Nginx, IIS, or another reverse proxy, RemoteIpAddress may show the proxy IP instead of the real client IP.

ASP.NET Core provides Forwarded Headers Middleware to process headers such as X-Forwarded-For and X-Forwarded-Proto.

But we should configure forwarded headers carefully because blindly trusting client-provided headers can create security problems.

Microsoft documentation: Configure ASP.NET Core to work with proxy servers and load balancers.

Pitfall 3: Queuing Too Many Requests

Rate limiting options often allow a queue.

limiterOptions.QueueLimit = 10;

This means rejected requests may wait instead of failing immediately.

That sounds useful, but it can be dangerous. If the system is already under pressure, a large queue can increase memory usage, latency, and timeout problems.

For many APIs, this is safer:

limiterOptions.QueueLimit = 0;

That means fail fast with 429 Too Many Requests.

Pitfall 4: Applying the Same Limit to Every Endpoint

Not all endpoints have the same cost.

GET  /api/products         -> cheap
POST /api/login           -> security-sensitive
GET  /api/reports/monthly -> expensive
POST /api/ai/summarize    -> expensive
POST /api/payment/process -> critical

A senior developer should not apply one random limit everywhere.

Better design:

Login endpoint: strict limit
Search endpoint: moderate limit
AI endpoint: token bucket limit
Report endpoint: concurrency limit
Health check endpoint: usually no rate limit or separate policy

Pitfall 5: Thinking Rate Limiting Solves DDoS Completely

Rate limiting helps, but it is not a complete DDoS solution.

A large distributed attack can come from many IP addresses and overwhelm the network before the ASP.NET Core app can make decisions.

In Azure, we should also think about:

Azure Front Door
Azure Web Application Firewall
Azure DDoS Protection
Azure API Management
Application Gateway WAF
CDN-level protection

Real-World Design Example

Imagine we are building a SaaS application with ASP.NET Core and Azure.

The application has these endpoints:

POST /api/auth/login
GET  /api/customers/search
POST /api/documents/summarize
GET  /api/reports/monthly
POST /api/orders

A good rate limiting design may look like this:

This is the type of answer senior interviewers like because it shows design thinking, not just syntax knowledge.

In senior .NET interviews, rate limiting in ASP.NET Core is usually discussed as part of API security, scalability, and production reliability.

Rate Limiting Interview Questions and Answers

1. What is rate limiting in ASP.NET Core?

Rate limiting controls how many requests a client, user, tenant, API key, or IP address can make within a defined rule.

In ASP.NET Core, we can use the built-in rate limiting middleware, configure global or named policies, and apply those policies to endpoints using RequireRateLimiting.

2. What status code should be returned when the rate limit is exceeded?

The common response is:

429 Too Many Requests

In ASP.NET Core, we can set:

options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

3. What is the difference between fixed window and sliding window?

Fixed window allows a certain number of requests in a fixed time period.

Example:

100 requests per minute

When the minute resets, the counter resets.

Sliding window divides the window into smaller segments. This gives smoother traffic control and avoids sudden bursts at the boundary of two windows.

4. When would you use token bucket?

I would use token bucket when the API should allow short bursts but still control average usage over time.

Good examples:

AI summarization API
Search API
External vendor API call
Notification API
Payment quote API

Token bucket is especially useful when the backend service has cost or quota limits.

5. When would you use concurrency limiter?

I would use concurrency limiter for expensive operations where simultaneous execution is the main concern.

Examples:

PDF generation
Excel export
Monthly report generation
Large database query
AI document processing

Concurrency limiter does not limit requests per minute. It limits how many requests can run at the same time.

6. Should we rate limit by IP address or user ID?

For anonymous traffic, IP address may be acceptable as a fallback.

For authenticated APIs, user ID, tenant ID, API key, or client ID is usually better.

IP-based limits can be inaccurate behind proxies, VPNs, corporate networks, and NAT gateways.

7. Where should rate limiting be placed in the middleware pipeline?

If endpoint-specific rate limiting is used, UseRateLimiter should be called after routing.

If the limiter depends on authenticated user information, place it after authentication so HttpContext.User is available.

app.UseRouting();

app.UseAuthentication();

app.UseRateLimiter();

app.UseAuthorization();

app.MapControllers();

8. How do you design rate limiting for a multi-tenant application?

I would partition rate limits by tenant ID.

For example:

Free tenant: 100 requests/minute
Professional tenant: 1,000 requests/minute
Enterprise tenant: custom limit

This is better than one global limit because each tenant gets fair usage.

9. Is rate limiting enough for security?

No. Rate limiting is one security layer, but it should be combined with:

Authentication
Authorization
Input validation
Web Application Firewall
DDoS protection
Logging and monitoring
Bot protection
API key management

Rate limiting helps reduce abuse, but it does not replace full API security.

10. How would you monitor rate limiting in production?

I would track:

Number of 429 responses
Top rejected users or IPs
Rejected requests by endpoint
Latency before and after rate limiting
Downstream service health
API cost trends

In Azure, I would usually monitor this using:

Application Insights
Azure Monitor
Log Analytics
Azure API Management analytics
Dashboard alerts

Senior-Level Interview Answer

You may also like my related article on resilient .NET APIs with retry, circuit breaker, timeout, and idempotency , because rate limiting is often used together with resilience patterns in production ASP.NET Core applications.

Final Thoughts

Rate limiting is a small feature with a big production impact.

For junior developers, it may look like middleware configuration.

For senior developers, it is an architecture decision.

A good rate limiting design protects the application, improves reliability, controls cloud and AI costs, and gives users a fair experience.

In real ASP.NET Core projects, I would always think about:

Who should be limited?
Which endpoint is expensive?
Should the limit be global, per user, per tenant, or per API key?
Should requests wait or fail fast?
How will we monitor 429 responses?
What happens behind a proxy or load balancer?

That is the difference between simply adding middleware and designing a production-ready API.