15. Rate Limiter
Design an API rate limiter
- Functional Requirements
- Server side rate limiting
- Clients should be informed of being rate limited (proper exception handling)
- Should be able to handle large number of requests
- should have clearly defined APIs such as allowRequest() that would return a boolean signifying if request is to be processed or dropped.
- Nonfunctional Requirements
- Fault tolerant: if rate limiter is down, it should not cause failures on the client applications. Failures needs to be handled
- Low latency: The rate limiting should not impact the application's response time. Our logic should be efficient and optimized
- Resource optimization: Rate limiter should not be too expensive to implement
- Highly available service (since our system is a standalone application that will be used by various other services, it should be highly available).
- When a new request arrives from the client, the Server first asks the Rate Limiter to decide if it will be served or rejected.
- If the request is not rejected, then it’ll be passed to the internal API servers.
- Rate Limiter’s responsibility is to decide which client request will be served and which request will be declined.
- Estimated Usage
- 100 request per minute / IP address
- 1,00,000 request per day processed overall
Seen this question in a real interview before?
Not all editor features are supported on mobile