Rate Limiting
1. The Problem
You've got an ASP.NET Core API running in Azure.
One of your endpoints is:
POST /api/orders
Under normal traffic, everything works fine.
Then something happens.
A buggy client starts sending hundreds of requests per second.
Or a third-party consumer accidentally creates a retry loop.
Or someone starts hammering your API.
Client
|
+---- Request
+---- Request
+---- Request
+---- Request
+---- Request
+---- Request
+---- Request
...
|
v
ASP.NET Core API
|
v
Database
Your application may still be perfectly healthy.
But suddenly the API has to process far more requests than it was designed for.
CPU increases.
Database connections increase.
Response times go up.
Eventually, legitimate users start seeing slow responses or failures.
The problem isn't necessarily that your application can't handle normal traffic.
The problem is that one client can consume too much of the available capacity.
2. What's Actually Going Wrong?
Without any limit, an API endpoint may effectively say:
“Send me as many requests as you want. I'll try to process all of them.”
That's dangerous for endpoints that are expensive or sensitive.
For example:
/api/orders /api/payments /api/search /api/reports
A single client making 10,000 requests doesn't just affect that client.
Those requests consume resources that other users also need.
API Capacity
|
+-------------+-------------+
| | |
User A User B User C
100 req 20 req 30 req
|
|
User D
10,000 req
|
v
Too much capacity
consumed by one client
This is where Rate Limiting comes in.
3. The Concept
Rate Limiting means:
Control how many requests a client is allowed to make within a defined period or according to a defined limit.
For example:
A client can make a maximum of 100 requests per minute.
Once the client reaches the limit:
Requests 1 - 100
|
v
Allowed
Request 101
|
v
Rejected
The API can return an HTTP 429 Too Many Requests response.
The basic mental model is:
Client | v Rate Limiter | +---- Within limit ----> API | +---- Over limit ------> 429
The rate limiter acts as a gate before requests consume significant application resources.
4. How Do You Fix It?
Suppose your API allows:
100 requests per minute per client
This uses the same gate you just saw: requests within the limit pass through, requests over it get a 429.
In ASP.NET Core, rate limiting can be configured using the built-in ASP.NET Core Rate Limiting middleware.
You can define policies that determine how requests should be limited.
For example, you might limit based on:
- Client
- IP address
- User identity
- API key
- Endpoint
The important part is deciding what you are protecting and who should share the limit.
For example, you may want:
Free API client -> 100 requests/minute Premium client -> 1,000 requests/minute
The exact limits depend on the application and business requirements.
5. What Happens When the Limit Is Reached?
Suppose a client has a limit of 100 requests per minute.
Request 101 gets the 429 from the gate. What matters more is what the client does next.
The client should not simply keep retrying immediately.
A well-designed API can communicate when the client should try again, commonly using response information such as Retry-After.
This is particularly important when clients implement automatic retries.
Otherwise you can end up with:
Rate limit reached
|
v
Client retries
|
v
Rate limit reached
|
v
Client retries
|
v
Rate limit reached
|
v
...
Your rate limiter may protect the API, but a badly designed retry loop can still generate unnecessary traffic.
6. Rate Limiting vs Throttling
You'll often hear rate limiting and throttling used together.
They are related, but the mental model can be slightly different.
Rate limiting is about enforcing a defined request limit.
For example:
“This client can make 100 requests per minute.”
Throttling is a broader idea of controlling or slowing down consumption when resources are under pressure.
For most API scenarios, the important concept is:
Don't allow one consumer to consume unlimited API capacity.
7. Visualize It in Everyday Terms
Imagine a popular restaurant with limited seating.
Without any control:
People | v Restaurant | v Everyone enters
Eventually the restaurant becomes overcrowded.
Customers can't move around.
Service slows down.
The staff becomes overloaded.
Now imagine a person at the entrance saying:
“We can only allow 50 people inside at a time.”
That's Rate Limiting.
In this analogy:
- Restaurant = API
- Customers = API clients
- Available tables = API capacity
- Person at the entrance = Rate Limiter
- Turning someone away temporarily = 429 Too Many Requests
The important lesson is:
The limit isn't there because every customer is bad.
It's there to make sure one customer can't consume all the available capacity and affect everyone else.
8. What Should You Remember?
Think about Rate Limiting as:
REQUEST
|
v
Rate Limiter
/ \
Within limit Over limit
| |
v v
API 429
Remember:
- Rate Limiting controls how many requests a client can make.
- It protects application and downstream resources.
- It prevents one client from consuming disproportionate capacity.
- ASP.NET Core provides built-in rate limiting capabilities.
- Choose the limit and partition carefully based on your application.
- Clients should handle 429 responses correctly instead of retrying aggressively.
The mental model is simple:
Put a controlled gate in front of your API so one consumer cannot overwhelm the system.
9. .NET + Azure Context
From a .NET engineer's perspective, don't think of Rate Limiting as simply:
“How do I reject requests?”
Think of it as:
“How much traffic should this consumer be allowed to generate before it starts affecting the rest of the system?”
