Michael Griffin

[MichaelPGriffin]

This design uses a Rate Limiter Policy abstraction to represent a given rate-limiter implementation.

I borrowed the /WeatherForecast controller as a familiar example API endpoint to apply the rate limiter policies against.

The x-api-key header acts as the access token for determining which rate limiter policies should be applied to a given request. The ApiKeyMiddleware class contains hard-coded API key values corresponding to different policies. Note that it's possible to configure this such that a single API key can be subject to multiple rate limiter policies if desired.

Since I took inspiration from the examples in the README, there is a "North American" policy that implements a sliding window rate limiter, as well as a "European" policy that implements a fixed window rate limiter. Unit tests for the rate limiter policies (implemented with xUnit) are stored in the RateLimiter.Tests project, and ensure the policies behave in ways that are expected.

The rate limiter is extendable: to add new rules, create a class that implements IRateLimiterPolicy and call it from the RateLimiterMiddleware. Also, the rate limiter and in-memory cache settings are configured in the appsettings.json. These values can be updated with minimal code changes.

For convenience, you can use these GET requests to trigger the rate limiter policies:

# API key subject to European policy (fixed window rate limiter):
 curl -k -X 'GET' 'https://localhost:7121/WeatherForecast' -H 'accept: text/plain' -H 'x-api-key: 49d3ad978e01a8fd57849bd56b66ae8d'

# API key subject to North American policy (sliding window rate limiter):
 curl -k -X 'GET' 'https://localhost:7121/WeatherForecast' -H 'accept: text/plain' -H 'x-api-key: 981729af12bac6b5e8e982aae064b96a'

# API key subject to both European and North American rate limiter policies:
 curl -k -X 'GET' 'https://localhost:7121/WeatherForecast' -H 'accept: text/plain' -H 'x-api-key: fd546133b56ccdd65a31b86a2b88dd9c'