Best way for implement rate limit in WebAPI

Approach 1: Built In ASP.NET Core Rate Limiter (Best Default)

If you are using .NET 7 or later, this should be your first choice.

Why this works

• Native framework support

• Extremely fast

• No external dependencies

• Works per endpoint, per user, or per IP

Step 1: Add Rate Limiter Services

using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

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

    options.AddPolicy("FixedPolicy", context =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: context.Connection.RemoteIpAddress?.ToString() ?? "unknown",
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 100,
                Window = TimeSpan.FromMinutes(1),
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            }));
});

Step 2: Enable Middleware

var app = builder.Build();

app.UseRateLimiter();
app.MapControllers();

app.Run();

Step 3: Apply to Controllers or Endpoints

[EnableRateLimiting("FixedPolicy")]
[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok("Rate limited endpoint");
    }
}

This limits each client IP to 100 requests per minute.

Advanced Policy: Token Bucket (Recommended)

Fixed windows are fine. Token buckets are better.

options.AddPolicy("TokenPolicy", context =>
    RateLimitPartition.GetTokenBucketLimiter(
        context.Connection.RemoteIpAddress?.ToString() ?? "unknown",
        _ => new TokenBucketRateLimiterOptions
        {
            TokenLimit = 50,
            TokensPerPeriod = 10,
            ReplenishmentPeriod = TimeSpan.FromSeconds(10),
            QueueLimit = 5,
            QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
            AutoReplenishment = true
        }));

This allows short bursts while maintaining a steady request rate.

Approach 2: Rate Limiting by User or API Key

IP based limiting breaks in mobile networks and behind NATs.

Use API keys or user IDs instead.

options.AddPolicy("UserPolicy", context =>
{
    var userId = context.User.Identity?.Name ?? "anonymous";

    return RateLimitPartition.GetFixedWindowLimiter(
        userId,
        _ => new FixedWindowRateLimiterOptions
        {
            PermitLimit = 200,
            Window = TimeSpan.FromMinutes(1)
        });
});

This is far more accurate for SaaS APIs.

Approach 3: Redis Based Rate Limiting (For Distributed Systems)

If you are running multiple instances behind a load balancer, in-memory rate limiting is not enough.

Redis becomes mandatory.

When to use Redis

• Kubernetes or autoscaling

• Multiple API instances

• Global rate limits across regions

High Level Flow

• Store counters in Redis

• Use Lua scripts for atomic increments

• Apply limits consistently across nodes

Example pseudo flow:

Request ? Redis INCR ? Check TTL ? Allow or Reject

Most teams use libraries or gateways instead of rolling this manually.

Approach 4: API Gateway Rate Limiting (Strongly Recommended)

Application level rate limiting should not be your only defense.

Put limits before traffic even hits your API.

Popular options:

• Azure API Management

• AWS API Gateway

• Kong

• NGINX

• Cloudflare

Example NGINX Rate Limiting

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

This blocks abuse before your app wakes up.

Best Practice Architecture (What Actually Works)

Real world production setup looks like this:

1. CDN or WAF for bot protection

2. API Gateway rate limiting

3. ASP.NET Core rate limiter per user

4. Concurrency limits on expensive endpoints

5. Redis for global enforcement

If you rely on only one layer, you will regret it.

Handling 429 Responses Properly

Always return meaningful headers.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Clients should know when to retry, not guess.

Common Mistakes to Avoid

• Only using IP based limits

• No limits on auth endpoints

• Same limit for all endpoints

• Forgetting burst traffic

• Logging nothing when throttling happens

Rate limiting without observability is useless.

Final Recommendation

If you want a straight answer:

• Small or medium API ? Built in ASP.NET Core Rate Limiter

• SaaS or public API ? Token bucket + user based limits

• Scaled system ? API gateway + Redis

• High risk endpoints ? Multiple layers always

Rate limiting is not a feature. It is a survival mechanism.