Getting Started With Rate Limiting In .NET Core API

Introduction

This is a series of two articles that will help you to learn about rate limiting and how can it be applied in a microservice or .net core API.

This series will cover the following things:

What is rate limiting?
Why do we use rate limiting?
Real-world use-case of rate limiting
Hands-on Lab – Create a WebAPI project and execute the API using swagger
Hands-on Lab – Implement Rate limiting using the AspNetCoreRateLimit Nuget Package
Difference between Rate Limiting and Throttling (To be covered in next Article)
Hands-on Lab – Implement Rate limiting using a Custom Middleware (To be covered in the next Article)

What is Rate limiting?

Rate limiting is the process of restricting the number of requests for a resource within a specific time window.
Rate limiting is the concept of limiting the amount a resource can be accessed. For example, you know that a database your application accesses can handle 1000 requests per minute safely, but are not confident that it can handle more than that. So, you can put a rate limiter in your application that allows 1000 requests every minute and rejects any more requests before they can access the database. The rate limiting of your database allows your application to handle a safe number of requests without potentially causing failures from your database.
A service provider offering an API for consumers will have limitations on requests made within a specified time window. For instance, each unique user/IP Address/Client key will have a limitation on the number of requests it can make to an API endpoint.

Why do we use Rate limiting?

Rate limiting helps protect against malicious bot attacks. For example, a hacker can use bots to make repeated calls to an API endpoint. This renders the service unavailable for anyone else. This is known as the Denial of Service (DoS) attack.
Another purpose of rate limiting is to regulate traffic to the API according to infrastructure availability. Such usage is more relevant to the cloud-based API services that utilize a “pay as you go” IaaS strategy with cloud providers.

Real-world use-case of Rate limiting

Public APIs use rate-limiting for commercial purposes to generate revenue. A common business model is to pay a certain subscription amount for leveraging the API. So, they can only make so many API calls before paying more for an upgraded plan.

Hands-on Lab – Create a WebAPI project and execute the API using swagger

Steps to be followed:

Open VS 2022 and create a project
Choose ASP.NET Core API as a template and create a directory

Once the web API project is been created, run the application and open swagger on local With URL - https://localhost:7134/swagger/index.html .

Execute the GET endpoint using swagger. Right now, we don’t have any rate limiting or throttling in place.

Hands-on Lab – Implement Rate limiting using the AspNetCoreRateLimit Nuget Package

Steps to be followed:

Install the NuGet named as – AspNetCoreRateLimit to implement Rate limiting on the API.

Once it is installed, go to the program.cs file and insert the following lines to add the services to implement rate limiting.

Now, add the configurations for limiting the rate from the particular IP.

Now, use the particular middle to implement the IP rate limiting.

Execute the application (Press F5) and execute the API from swagger for the first time. If you see the below screenshot, the quota for API calls for that particular API has been decreased by one, i.e., 1.

Execute the API from swagger for the second time. If you see the below screenshot, the quota for API calls for that particular API has been decreased by one, i.e. 0 -.

Execute the API from swagger for the third time, and if you see the below screenshot, the quota for API calls for that particular API has been exceeded.

This is how we implemented rate limiting using AspNetCoreRateLimit Nuget Package, although the second approach will be covered in the next article on implementing rate limiting using custom middleware.

I've attached the source code for your reference.

Happy learning!