Check out my courses:
Come to NDC Oslo:
Become a Patreon and get source code access:
Hello everybody I’m Nick and in this video I will introduce you to the brand new rate limiting functionality that was introduced in .NET 7. Like with anything that is in preview, this is subject to change but we will take a look at the concepts behind the rate limiting itself which will stay the same.
Don’t forget to comment, like and subscribe 
Social Media:
Follow me on GitHub:
Follow me on Twitter:
Connect on LinkedIn:
Keep coding merch:
#csharp #dotnet
Please make a video on ratelimit with redis
Hi Nick, thanks for your video. It would be great to have a dedicated video about this rate limiter in .net 8.
So this is not for limiting external api call?
This can used with graphql apis?
thanks Nick. Do you know if this is deprecated or dropped? Still shows as an RC and last update was on October 2022.
Thanks for the video, do you have an updated one now dotnet is released? Thanks!
Hi Nick, how does Rate Limit handles real IP that are behind Proxy like for example Cloudflare where they send CF-Connecting-IP header for each request?
Ok, but this is a job for ingress controller. Better will be a distributed (redis) restsharp extension to not hit those limits.
Are all the buckets for the partitions in memory? I.e. can I create one per client (IPv6) ip?
Hey Nick, big fan.
wanted to point out that in the definition of Limiter when you define the RateLimiterOptions you can see there is a class called NoLimiter which is also a PartitionedRateLimiter
Great demonstration
What do you think of Azure API Management? I like the idea of wrapper my services to handle the boring stuff, expectantly since I don't have to build/maintain it. Cost and customization are the obvious trade-offs though.
As I watched the video, the question of distributed rate limiting automatically popped up and I'm happy that Nick also addressed this; should be possible to use e.g. Redis for a quite clean setup.
Rate limit parameters can be changed runtime?
Thank you Nick for this interesting video!
As you pointed out, as of now, having no type of external, persistent and shared memory integration is a lack, but surely they‘ll work on it.
Even in a single instance scenario would be a problem when you republish or restart the application..
I’m also wondering if there’s some method to intercept when requests are going to be refused due to limits hit?
Would be interesting to do things like notify the user or store the event in a database.
Anyway, great idea that is surely going to be useful!
It would be grate to use it it pair with YARP. But yep, multiple instances case must be handled somehow first.
In high-throughput scenarios Redis might be a bottleneck. I think it would be better to store limiting state in each instance memory and update it in the background from the common queue. Not that accurate, but should be much more performant.
For me this can be done in 1 min by Nodejs
What software do you use to draw rectangles and arrows?
Do we get access to the DI container??
If you've multiple pods running for same service, how will this work?
If it is just a middleware why it requires NET 7?
Great. But I'm wondering does it realy make sense to have on Api layer? I asume almost all systems where rate limiting required are big enough to have either Api gateway or loadbalancer etc. Even if you don't use any of them it's likely possible that you will run more then one instance of your Api.
So, don't see real cases for production. Maybe for some small projects. Or with some Redis behind that was mentioned in the video.