Rate Limiting in ASP.NET Core – Protect Your APIs Like a Pro

Imagine this: your API gets hammered with 10,000 requests per second from a single IP. Your server crashes, legitimate users can’t access your service, and you’re losing money.

With proper rate limiting, you can block that attack and keep serving your real users.

That’s the power of rate limiting — your first line of defense against API abuse.

In this guide, we’ll explore how to implement rate limiting in ASP.NET Core, different algorithms, when to use each one, distributed scenarios with Redis, and we’ll run benchmarks to see the protection in action.

🔍 What is Rate Limiting?

Rate limiting is a technique to control the number of requests a client can make to your API within a specific time window.

Benefits:

• Prevents DDoS attacks and API abuse
• Protects server resources under heavy load
• Ensures fair usage among clients
• Improves overall API stability

Trade-offs:

• Legitimate users might get blocked during traffic spikes
• Additional complexity in distributed scenarios
• Slight performance overhead

📑 Types of Rate Limiting Algorithms

Fixed Window

Time: 0s----10s----20s----30s
Reqs: [10]   [10]   [10]   [10]

Allows X requests per fixed time period. Simple but can allow traffic spikes at window boundaries.

Sliding Window

Time: Continuous sliding window of 10 seconds
Reqs: Always checking last 10 seconds of activity

More smooth and fair — prevents boundary spike issues.

Token Bucket

Bucket: [🪙🪙🪙🪙🪙] (5 tokens)
Request: Takes 1 token, refills over time

Allows controlled bursts while maintaining average rate.

Concurrency Limiting

Active requests: [1][2][3] (max 3 concurrent)
New request: ❌ Blocked until one completes

Limits simultaneous active requests rather than total requests.

🖼 How Rate Limiting Works – Visual Overview

Without Rate Limiting:
Client --> [1000 req/s] --> Server 💥 (Overloaded)

With Rate Limiting:
Client --> [100 req/s allowed] --> Server ✅ (Stable)
        --> [900 req/s blocked] --> 429 Too Many Requests

The rate limiter acts as a gatekeeper, allowing legitimate traffic while blocking abuse.

📦 Setting Up (.NET 7+ Native Support)

ASP.NET Core 7+ includes built-in rate limiting middleware:

dotnet new webapi -n RateLimitingDemo
cd RateLimitingDemo

🛠 Implementation Examples

Basic Fixed Window Setup

using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

// Add rate limiting services
builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("ApiPolicy", opt =>
    {
        opt.Window = TimeSpan.FromMinutes(1);
        opt.PermitLimit = 100;
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 10;
    });

    options.OnRejected = async (context, token) =>
    {
        context.HttpContext.Response.StatusCode = 429;
        await context.HttpContext.Response.WriteAsync(
            "Too many requests. Try again later.", token);
    };
});

var app = builder.Build();

// Enable rate limiting middleware
app.UseRateLimiter();

// Apply rate limiting to endpoints
app.MapGet("/api/products", () => "Here are your products!")
   .RequireRateLimiting("ApiPolicy");

app.Run();

Sliding Window Implementation

builder.Services.AddRateLimiter(options =>
{
    options.AddSlidingWindowLimiter("SlidingPolicy", opt =>
    {
        opt.Window = TimeSpan.FromMinutes(1);
        opt.PermitLimit = 100;
        opt.SegmentsPerWindow = 6; // 10-second segments
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 10;
    });
});

Token Bucket for Burst Traffic

builder.Services.AddRateLimiter(options =>
{
    options.AddTokenBucketLimiter("BurstPolicy", opt =>
    {
        opt.TokenLimit = 100;
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 10;
        opt.ReplenishmentPeriod = TimeSpan.FromSeconds(10);
        opt.TokensPerPeriod = 20;
        opt.AutoReplenishment = true;
    });
});

Per-User Rate Limiting

builder.Services.AddRateLimiter(options =>
{
    options.AddPolicy("PerUserPolicy", httpContext =>
    {
        var userId = httpContext.User?.FindFirst("sub")?.Value ?? "anonymous";
        
        return RateLimitPartition.GetFixedWindowLimiter(userId, _ =>
            new FixedWindowRateLimiterOptions
            {
                PermitLimit = GetUserLimit(userId), // Different limits per user type
                Window = TimeSpan.FromMinutes(1)
            });
    });
});

static int GetUserLimit(string userId)
{
    return userId switch
    {
        "anonymous" => 10,      // Anonymous users: 10 req/min
        var id when IsPremiumUser(id) => 1000,  // Premium: 1000 req/min
        _ => 100               // Regular users: 100 req/min
    };
}

Controller-Level Rate Limiting

[ApiController]
[Route("api/[controller]")]
[EnableRateLimiting("ApiPolicy")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult GetProducts()
    {
        return Ok(new { Message = "Here are your products!" });
    }

    [HttpPost]
    [EnableRateLimiting("StrictPolicy")] // Different policy for POST
    public IActionResult CreateProduct([FromBody] Product product)
    {
        return Ok(new { Message = "Product created!" });
    }
}

⚡ Benchmark 1 – API Protection Under Load

Let’s measure how rate limiting protects our API under heavy load:

Test Setup:

// Load test simulation
public async Task SimulateLoad(int requestsPerSecond, int durationSeconds)
{
    var client = new HttpClient();
    var tasks = new List<Task<HttpResponseMessage>>();
    
    for (int i = 0; i < requestsPerSecond * durationSeconds; i++)
    {
        tasks.Add(client.GetAsync("https://localhost:7001/api/products"));
        
        if (i % requestsPerSecond == 0)
            await Task.Delay(1000); // Wait 1 second
    }
    
    var responses = await Task.WhenAll(tasks);
    
    var successCount = responses.Count(r => r.IsSuccessStatusCode);
    var rateLimitedCount = responses.Count(r => r.StatusCode == HttpStatusCode.TooManyRequests);
    
    Console.WriteLine($"Successful: {successCount}");
    Console.WriteLine($"Rate Limited: {rateLimitedCount}");
}

Results (100 req/min limit):

⚡ Benchmark 2 – Algorithm Performance Comparison

Comparing different rate limiting algorithms under the same load:

Memory Usage & Response Times:

Winner: Concurrency limiting for lowest latency, Fixed Window for lowest memory usage.

📌 Distributed Rate Limiting with Redis

For multi-instance applications, you need distributed rate limiting:

dotnet add package StackExchange.Redis

public class RedisRateLimitService
{
    private readonly IDatabase _database;
    
    public RedisRateLimitService(IConnectionMultiplexer redis)
    {
        _database = redis.GetDatabase();
    }
    
    public async Task<bool> IsAllowedAsync(string key, int limit, TimeSpan window)
    {
        var script = @"
            local current = redis.call('GET', KEYS[1])
            if current == false then
                redis.call('SET', KEYS[1], 1)
                redis.call('EXPIRE', KEYS[1], ARGV[2])
                return 1
            else
                local count = tonumber(current)
                if count < tonumber(ARGV[1]) then
                    redis.call('INCR', KEYS[1])
                    return 1
                else
                    return 0
                end
            end";
        
        var result = await _database.ScriptEvaluateAsync(
            script, 
            new RedisKey[] { key }, 
            new RedisValue[] { limit, (int)window.TotalSeconds }
        );
        
        return result.ToString() == "1";
    }
}

// Usage in middleware
public class CustomRateLimitMiddleware
{
    private readonly RequestDelegate _next;
    private readonly RedisRateLimitService _rateLimitService;
    
    public async Task InvokeAsync(HttpContext context)
    {
        var clientId = GetClientIdentifier(context);
        var isAllowed = await _rateLimitService.IsAllowedAsync(
            $"rate_limit:{clientId}", 
            100, 
            TimeSpan.FromMinutes(1)
        );
        
        if (!isAllowed)
        {
            context.Response.StatusCode = 429;
            await context.Response.WriteAsync("Rate limit exceeded");
            return;
        }
        
        await _next(context);
    }
}

🚫 Common Pitfalls and When NOT to Use

Avoid rate limiting when:

• Internal APIs between your own services
• Development environments (can slow down testing)
• Very low traffic APIs (overhead > benefit)

Common mistakes:

• Too restrictive limits that block legitimate users
• Not considering different user tiers (anonymous vs authenticated vs premium)
• Forgetting about distributed scenarios (each instance has separate limits)
• Not providing clear error messages to blocked clients

📈 Advanced Features

Custom Headers for Better UX

options.OnRejected = async (context, token) =>
{
    var response = context.HttpContext.Response;
    response.StatusCode = 429;
    response.Headers.Add("X-RateLimit-Limit", "100");
    response.Headers.Add("X-RateLimit-Remaining", "0");
    response.Headers.Add("X-RateLimit-Reset", DateTimeOffset.UtcNow.AddMinutes(1).ToUnixTimeSeconds().ToString());
    response.Headers.Add("Retry-After", "60");
    
    await response.WriteAsync("Rate limit exceeded. Try again in 60 seconds.", token);
};

IP-based Rate Limiting

options.AddPolicy("IpPolicy", httpContext =>
{
    var ipAddress = httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown";
    
    return RateLimitPartition.GetFixedWindowLimiter(ipAddress, _ =>
        new FixedWindowRateLimiterOptions
        {
            PermitLimit = 100,
            Window = TimeSpan.FromMinutes(1)
        });
});

✅ Conclusion

Rate limiting is essential for API security and stability. With ASP.NET Core 7+, implementing it is straightforward and powerful.

Key takeaways:

• Use Fixed Window for simplicity and lowest memory usage
• Use Sliding Window for smoother, fairer rate limiting
• Use Token Bucket when you need to allow controlled bursts
• Use Concurrency limiting for protecting resource-intensive operations
• Always implement distributed rate limiting for multi-instance deployments
• Provide clear error messages and retry information to clients
• Test your limits with realistic load scenarios

Choose your algorithm based on your specific needs, and always monitor the impact on both performance and user experience.

📖 Further reading:

• ASP.NET Core Rate Limiting
• System.Threading.RateLimiting Documentation
• Redis Rate Limiting Patterns