Interview Preparation [Short Form]: Designing A Rate Limiter
Hi there. Hope you all are doing well :). We just hit 3000+ subscribers ❤️❤️❤️ Thank you for your support :)
This blog post is an experiment with a different model - where I am testing out a short form of blog and see if it works for the readers. If this doesn’t work, then I will go back to the longer form, low-volume model. This blog post consists of the following parts:
Part I: Quick Recap Of The Last Two Blog Posts On Interview Preparation.
Part II: High-Level Design Of A Rate Limiter (Single Microservice).
Part III: Feedback From You.
Part I: Quick Recap: In the previous two blog posts we covered the following:
I) Design A System To Get TopK Elements At Scale.
II) Designing A Distributed Cache.
Part II: Summary Of A Rate Limiter (Single Microservice)
A common question asked in System Design Interviews is about the design of a Rate Limiter. I have shared the High-Level Design of a simple rate-limiter for a single Microservice in this post. The most important components of the design are as follows:
1. Client Identifier: The Client Identifier identifies the client based on the session credentials, client IP, or browser signatures. It ensures that each request is correctly attributed to the requesting client.
2. Throttle Rules Service Client: A client to send requests to the Throttle Rules Microservice.
3. Throttle Rules Retriever: A module that gets the set of applicable rules from the rules processing engine.
4. Rules Processor: The core engine that retrieves all the rules from secondary storage (such as a Database) and decides whether the request should be processed or not.
5. Rules Database: The rules database contains all the rules governing how requests should be throttled.
6. Rules Console: A console engine that the administrator can use to create, read, update, or delete rules.
Response: The Rate Limiter Micro-Service can respond back to the client with the following responses:
Success: 200, OK.
Failure: 429 (Too Many Requests) or 503 (Service Unavailable).
Part III: In order to improve the Newsletter, I would love to hear from you. Drop a comment on this post or share your feedback on the form linked below. You can share what topics you consider valuable, newsletter formats, frequency, and/or whether videos make more sense than text blogs.
Cheers,
Ravi.