Building modern APIs and Connectors with Rate Limitation

One year ago, Microsoft published the Rate Limitation Feature within ASP.NET 7.0. This seamlessly silent and mostly unknown feature is indeed not an everyday-used feature. However, it can be helpful in solving many common issues when working with cloud applications.

For example, think about following scenarios:

• Prevent DoS attacks
• Manage Resource Utilization
• Cost Controlling
• SKU Based Throttling

By implementing rate limitation, an application restricts the rate at which requests are accepted or processed by using various algorithms.

Prevent DoS attacks

Preventing Denial-of-Service (DoS) attacks with rate limitation involves setting limits on the number of requests or actions that can be performed within a certain timeframe. This helps to mitigate the impact of malicious or excessive traffic that could overload a system or exhaust its resources.

Rate Limitatin prevents an attacker from flooding the application with a large number of requests and causing it to become unresponsive.

Manage Resource Utilization

Managing resource utilization with rate limiting involves setting limits on the rate at which resources are consumed by applications or users. This helps to ensure fair usage, prevent abuse, and maintain system stability.

Cost Controlling

Cost controlling with rate limitation involves managing and optimizing the usage of resources to control expenses and minimize costs associated with cloud services or other pay-per-use systems. This can be particularly important in scenarios where cloud services or third-party APIs are billed based on usage or subscription tiers.

SKU Based Throttling

SKU-based throttling is a technique used to control resource usage based on different service tiers or pricing plans, known as Stock Keeping Units (SKUs). It involves applying rate limitation rules specific to each SKU to manage the access and consumption of resources.

With SKU-based throttling, different levels of service or pricing plans are associated with distinct rate limits. This means that users or applications subscribed to a particular SKU will have their resource usage governed by the predefined rate limits associated with that SKU.

By using rate limitation in conjunction with SKUs, organizations can offer differentiated levels of service to their customers or users. Each SKU may come with its own set of rate limits, which can restrict the number of API calls, data transfers, or other resource-intensive actions that can be performed within a given timeframe.

Following code-snippet shows how to configure the Rate Limiter:

  limiterOptions.AddPolicy(policyName: jwtPolicyName, partitioner: httpContext =>
  {
     var accessToken = httpContext.Request.Headers["ApiKey"];

     if (!StringValues.IsNullOrEmpty(accessToken))
     {
         int permitLimit;

         var principal = 
         apiKeyCfg.Keys.FirstOrDefault(k => k.KeyValue == accessToken);
         
         if (principal == null)
             throw new UnauthorizedAccessException("Unkown key.");

         if (principal.PrincipalName == "Key1-BasicSKU")
             permitLimit = 3;
         else
             permitLimit = 1000;

         return RateLimitPartition.GetFixedWindowLimiter(accessToken, _ =>
         new FixedWindowRateLimiterOptions
         {
             QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                               QueueLimit = permitLimit,
                               Window = TimeSpan.FromMinutes(1),
                               PermitLimit = permitLimit,
                               AutoReplenishment = true
                           });
          }
   }

More about this at European Collaboration Summit: https://www.collabsummit.eu/