First of all, what is a rate limiter and why do we use it?

• almost every software system, product or service uses some sort of rate limiting and not only for pricing tier goal ; )
• preventing DoS attacks. With rate limiting, we are basically limiting the amount of traffic our system can handle in a given time period - seconds, minutes, days.. As a by-product of that, we get better ownership of the traffic and how it can be handled. Whether is is a blackFriday type of burst or someone just tries to attack us by initiating millions of requests via some bot script.
• by using rate limiting, we can set a bunch of limitations - on the client-side and/or on the server-side, and/or in between. It really depends on the system we are working at and the aim of the rate limiting.
• we can limit based on amount of requests to the API / IP Addresses / Profile creations / Number of likes per minute per user..

There are some core ways in which we can implement a rate limiter in the system:

• on the client side. Not best as some malicious user can potentially play around with the parameters and limitations we’ve set through manipulating the requests/params we use
• on the server side. This is the typical way of setting such limiter. We can decide whether it can stay on the application side or as malware in between the client and the server (potentially as part of the API Gateway)

1st - Defining the requirements and asking pre-clarifying questions

In the first 5-10 minutes or so, we can ask some questions, related to the things we’ve mentioned above. Qs like:

• What are we limiting on? IP addresses, requests per second, likes and follows?
• How many traffic or load are we expected to have for this application?
• Are we designing the rate limter to work in a distributed system?
• Is the rate limiter going to be on the server or client side?

We need to ask questions that will help us get a broader picture of what the interviewer wants us to do and how should we go about designing the limiter..