Rate-limiting pattern

Rate limiting involves restricting the number of requests that a client can make. A client is identified with an access token, which is used for every request to a resource. To prevent abuse of the server, APIs enforce rate-limiting techniques. The rate-limiting application can decide whether to allow the request based on the client. The client makes an API call to a particular resource; the server checks whether the request for this client is within the limit. If the request is within the limit, then the request goes through. Otherwise, the API call is restricted.

Some examples of request-limiting rules (you could imagine any others)

• X requests per timespan;
• a certain timespan has passed since the last call;
• For US-based tokens, we use X requests per timespan; for EU-based tokens, a certain timespan has passed since the last call.

The goal is to design a class(-es) that manages each API resource's rate limits by a set of provided configurable and extendable rules. For example, for one resource, you could configure the limiter to use Rule A; for another one - Rule B; for a third one - both A + B, etc. Any combination of rules should be possible; keep this fact in mind when designing the classes.

We're more interested in the design itself than in some intelligent and tricky rate-limiting algorithm. There is no need to use a database (in-memory storage is fine) or any web framework. Do not waste time on preparing complex environment, reusable class library covered by a set of tests is more than enough.

There is a Test Project set up for you to use. However, you are welcome to create your own test project and use whatever test runner you like.

You are welcome to ask any questions regarding the requirements—treat us as product owners, analysts, or whoever knows the business. If you have any questions or concerns, please submit them as a GitHub issue.

You should fork the project and create a pull request named as FirstName LastName once you are finished.

Good luck!