Rate Limiting and API Throttling in ASP.NET Core .NET 8

Introduction

.NET 8 built-in rate limiting protects ShopNest public API from abuse — fixed window, sliding window, token bucket — no third-party library required.

After this article you will

• Configure fixed and sliding window limiters
• Per-user limits by API key claim
• Return RateLimit headers on responses
• Chain global + endpoint policies
• Distributed limiting with Redis

Prerequisites

• Article 72 — gRPC, GraphQL and Alternative APIs
• Articles 1–64 ShopNest foundations (MVC, EF Core, API, auth, deploy)

Architecture & design

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("api", opt =>
    {
        opt.Window = TimeSpan.FromMinutes(1);
        opt.PermitLimit = 100;
        opt.QueueLimit = 0;
    });
    options.OnRejected = async (ctx, token) =>
    {
        ctx.HttpContext.Response.StatusCode = 429;
        await ctx.HttpContext.Response.WriteAsync("Too many requests", token);
    };
});
app.UseRateLimiter();

[EnableRateLimiting("api")]
[HttpGet("products")]
public IActionResult List() => Ok(...);

Hands-on build guide — ShopNest Public API Fair Use Policy

1. Apply 100 req/min on public catalog API.
2. Stricter 10 req/min on /auth/login.
3. Partition by API key header for partner tiers.
4. Load test with k6 — verify 429 responses.

Common pitfalls

• Rate limit after auth middleware — partition by user ID correctly.
• No 429 body — clients can't tell throttle vs error.

Interview & portfolio questions

Q: Token bucket vs fixed window?
A: Token bucket allows bursts; fixed window resets each interval.

Summary

• Built-in rate limiting replaces custom middleware for most cases
• 429 + headers = fair use transparency
• Redis partition for multi-instance ShopNest

Previous: gRPC, GraphQL and Alternative APIs
Next: Output Caching

FAQ