Welcome to the very first lesson of the "implementing rate limiting" course! 🚀

In this lesson, we'll explore one of the most fundamental yet powerful security mechanisms in modern API development: rate limiting. Whether you're building a small web service or a large-scale API, understanding and implementing rate limiting is essential for protecting your application from abuse, managing resources efficiently, and ensuring fair access for all users.

By the end of this lesson, you'll have a working implementation of a global rate limiter protecting all your API endpoints. You'll understand not just the "how" but also the "why" behind this critical security feature. Let's dive in! 🎉

Rate limiting is a defensive strategy that controls how many requests a client can make to your API within a specified time period. Think of it as a bouncer at a club, keeping track of how many times someone tries to enter and enforcing the house rules.

Each client is identified by some unique characteristic — typically an IP address, but it could also be an API key, user ID, or other identifiers. When a client reaches their allotted number of requests within the time window, the rate limiter steps in and blocks subsequent requests until the time period resets.

For example, you might configure your API to allow each client:

• No more than 5 requests per minute for testing purposes.
• No more than 100 requests per hour for standard users.
• No more than 1000 requests per day for premium accounts.

These limits act as guardrails, protecting both your infrastructure and your users from problematic behavior.

Rate limiting isn't just about saying "no" to excessive requests — it's a multifaceted security and performance tool that provides several critical benefits:

Prevents server overload — Your server has finite resources: CPU cycles, memory, database connections, and network bandwidth. Rate limiting ensures that these resources aren't exhausted by a flood of requests, keeping your service responsive for all users.

Defends against DoS attacks — Distributed Denial of Service attacks attempt to overwhelm your API with massive volumes of requests. While rate limiting won't stop sophisticated DDoS attacks entirely, it significantly raises the bar for attackers and protects against simpler flooding attempts.

Ensures fair usage — Without rate limiting, a single aggressive client could monopolize your API, degrading service quality for everyone else. Rate limits create a level playing field where all clients get their fair share of resources.

Manages traffic spikes — Legitimate traffic can spike unexpectedly — a viral post, a marketing campaign, or a sudden surge in popularity. Rate limiting helps smooth out these spikes, preventing your infrastructure from buckling under sudden load.

Reduces costs — Many cloud services charge based on resource consumption: API calls to third-party services, database queries, or compute time. By limiting excessive usage, you also limit your operational costs.

Understanding where rate limiting happens in your application's request flow is crucial for effective implementation. In ASP.NET Core, rate limiters work as part of the middleware pipeline — a chain of components that process each incoming HTTP request.

Here's how the middleware pipeline works:

1. Sequential execution — Middleware components are executed in the exact order they're added to the IApplicationBuilder in your Program.cs file.

2. Request processing — Each middleware can inspect and modify the incoming request, perform authentication, logging, or other cross-cutting concerns.

3. Pipeline control — Middleware decides whether to pass the request to the next component (next()) or short-circuit the pipeline and return a response immediately.

4. Rate limiting interception — When properly configured, the rate limiting middleware sits early in this pipeline, checking each request against the client's rate limit before expensive operations occur.

5. Quick rejection — If a client has exceeded their limit, the middleware responds with a 429 Too Many Requests status code and stops processing, never reaching your controllers or business logic.

This architecture is elegant because it allows rate limiters to protect your application before any resource-intensive work begins — before database queries, before complex calculations, before external API calls.

Let's examine our application's starting point. Right now, we have a basic ASP.NET Core API with no rate limiting whatsoever. Here's our Program.cs:

This minimal configuration maps routes directly in Program.cs using ASP.NET Core's minimal API style, but provides zero protection against request flooding.

Our application includes a test endpoint for verifying rate limiting behavior:

We also have an authentication route ready for future use:

Without any rate limiting, these endpoints are completely vulnerable to abuse. An attacker could bombard them with thousands of requests, potentially overwhelming your server.

Without rate limiting, your API is an open target. Consider how easily an attacker could exploit this vulnerability:

This basic script sends 100 requests in rapid succession. Now imagine scaling this up — thousands of requests per second from multiple machines. Even if each individual request is lightweight, the cumulative effect can:

• Exhaust server resources — CPU, memory, and network connections all have limits.
• Degrade database performance — If your endpoints query a database, you could overwhelm it with connections.
• Trigger cascading failures — Overloaded services often fail unpredictably, causing ripple effects throughout your system.
• Inflate costs — Cloud providers charge for resource usage, and an attack could result in an unexpectedly large bill.

The solution? Let's implement rate limiting to stop these attacks before they cause damage.

ASP.NET Core 7.0 and later versions include powerful built-in rate limiting capabilities, eliminating the need for third-party libraries. The first step is registering the rate limiting services with your application's dependency injection container.

Add this to your Program.cs before building the app:

This single method call does several things behind the scenes:

• Registers the rate limiter services with the DI container.
• Prepares the infrastructure for tracking request counts per client.
• Sets up the foundation for the middleware we'll add later.

Now we're ready to configure how our rate limiting will actually work.

With the services registered, we need to define our rate limiting policy. We'll use a fixed window limiter, which divides time into discrete windows and tracks requests within each window.

Instead of creating a named policy that must be explicitly applied to each route, we'll assign our limiter to the GlobalLimiter property. This approach automatically applies rate limiting to every request without requiring any per-route configuration.

Add this configuration inside the AddRateLimiter call:

Let's break down each part of this configuration:

GlobalLimiter — Unlike a named policy that requires explicit opt-in per route, GlobalLimiter intercepts every incoming request before it reaches any route handler. It acts as a global checkpoint for the entire application.

PartitionedRateLimiter.Create — This creates a rate limiter that maintains separate counters for different clients. Each client gets their own independent counter, so one client hitting their limit doesn't affect anyone else.

Partition key (IP address) — We identify each client by their IP address using httpContext.Connection.RemoteIpAddress. The ?? "unknown" fallback handles edge cases where the address can't be determined.

RateLimitPartition.GetFixedWindowLimiter — This instructs the partitioned limiter to use the fixed window algorithm for each partition, giving every unique IP address its own fixed window counter.

Now that we've configured our rate limiting policy, we need to activate the middleware that will enforce it. Middleware order matters in ASP.NET Core, so we'll add the rate limiter before we map our routes.

Add these lines to your Program.cs:

The UseRateLimiter() method inserts the rate limiting middleware into your request pipeline. Because we've configured a GlobalLimiter, the middleware will automatically apply our rate limiting policy to every incoming request, regardless of which route it targets.

With the GlobalLimiter in place, there's nothing more to configure here — the policy is already applied to all endpoints automatically. Every request that passes through UseRateLimiter() is checked against our global limit, with no need to annotate individual routes.

This is a key advantage of GlobalLimiter over named policies. A named policy approach would require explicit opt-in on every route:

With GlobalLimiter, you can never accidentally leave a new endpoint unprotected simply by forgetting to attach a policy.

Here's how the complete Program.cs looks with all our changes:

With this configuration in place, every endpoint is now protected by our rate limiter. Let's verify it works.

Testing is crucial to ensure our rate limiter behaves as expected. We'll create a simple C# console application that sends multiple requests to our test endpoint.

Create a new console project and add this code:

This script sends 10 requests with a tiny delay between them. When you run it, you should see output like this:

Perfect! The first five requests succeed, and the rest are rejected with 429 status codes. Our rate limiter is working exactly as configured.

Important note: Your actual output may vary slightly depending on timing factors. System delays, network latency, or longer gaps between requests can affect when the rate limit kicks in. The key pattern to observe is that after approximately 5 successful requests, you should consistently see 429 responses.

Congratulations! You've just implemented a robust global rate limiter that protects all your API endpoints from abuse. Let's reflect on what we've built and why it matters.

With just a few strategic additions to Program.cs, we've transformed our vulnerable API into one that can withstand basic flooding attacks. Our rate limiter now:

• Tracks requests per client automatically.
• Enforces our 5 requests per 30 seconds limit consistently.
• Responds with appropriate HTTP status codes when limits are exceeded.
• Protects all endpoints without requiring per-endpoint configuration.

This is a significant security improvement, but it's also just the beginning. As you might have noticed, our global rate limiter treats all endpoints and all clients the same way. In real-world applications, you'll often need more nuance:

Different limits for different endpoints — Your authentication endpoint might need stricter limits than a public read-only endpoint.

User-based rate limiting — Premium users might get higher limits than free-tier users.

More sophisticated algorithms — Fixed windows can have edge cases; sliding window or token bucket algorithms might be better for your use case.

Dynamic limits — Adjust limits based on current server load or time of day.

In upcoming lessons, we'll explore these advanced scenarios, learning how to:

• Apply different rate limiting policies to specific routes or endpoints.
• Create specialized limiters for authentication endpoints with stricter rules.
• Implement sliding window and token bucket algorithms for smoother rate limiting.
• Use partition keys to apply different limits based on user roles, API keys, or other criteria.
• Handle rate limiting in distributed systems with multiple servers.

Rate limiting is a fundamental building block of API security, but it's most effective when combined with other security measures like authentication, authorization, input validation, and monitoring. Together, these practices create a defense-in-depth strategy that keeps your application secure and performant.

In the next lesson, we'll take our rate limiting to the next level by learning how to apply different limits to different parts of your API. See you there! 🚀