A Rate Limiter limits the number of client requests allowed to be sent over a specified period. If the API request count exceeds the threshold defined by the rate limiter, all the excess calls are blocked.

For example, A user can only post up to 10 times in 1 minute, a user can only create up to 10 accounts per day from the same IP address, etc.

Before deep-diving into the implementation of a rate limiter, let’s look at its benefits:

A rate limiter prevents DoS attacks, intentional or unintentional, by blocking the excess calls.

Reduces cost where the system is using a 3rd-party API service and is charged on a per-call-basis.

To reduce server load, a rate limiter is used to filter out excess requests caused by bots or users’ misbehaviour.

It mainly depends upon our application, tech stack, tech-team etc, where exactly we want the rate-limiter to be implemented. We have generally 3 places: Client-side, Server-side, or middleware.

The client is an unreliable place to enforce rate limiting because client requests can easily be forged by malicious actors.

Even better than placing it on the server side is to use a rate limiter middleware, which will throttle excess requests even to our server side. So, if you are using a microservice architecture and already using functionalities like authentication middleware, a similar basis you can implement rate limiter middleware alongside it.