Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
To limit the number of requests a clinet can send to and API
To make sure the client gets
List non-functional requirements for the system...
Latency - System should have low latency so the api should not take much time
Availability - System should be highly available as being system unavailable can cause high risk to the system
Estimate the scale of the system you are going to design...
The number of requests per minute =10,000 then QPS =10,000/60 =166.6667
Define what APIs are expected from the system...
Api design is irrelevant for this question.+
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
For Rate limiting we will be internal cache such as redis for storing the key and value where key will be uniquley generated by using the id adrees and some other details and key will be the counter of the number of request the user has made till now and also we will be storing the rules of how many apis are allowed from this uniquely generated id and these rules will be stored in redis becuase of low latency
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
The Placement of rate limiter is key as the rate limiter cannot be placed at the client side because at client side it can easily be tempered and also it cannot be placed at the server side as synchronization will be an issue so we should place rate limiter in between the client and server like api gatteway . Different algorithms are present for rate limiting we will usse tocken bucket algorithm.
The request from the client will go to the load balancer and from the load balancer the call will go to the api gateway where the rate Limiter is presnt
The rate limiter first get the rules for the api from the redis cache and based on the ip address it generated a unique key then it again queries the redis back to check if the counter +1 statifies the rules if the rules are satified then call is reidtected to api server else call will be redirected to user saying status 429 too many calls. In case of any failures the requests will be stored in the queue and these request will be processed again once the issue is resolved.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
The request from the client will go to the load balancer and from the load balancer the call will go to the api gateway where the rate Limiter is presnt
The rate limiter first get the rules for the api from the redis cache and based on the ip address it generated a unique key then it again queries the redis back to check if the counter +1 statifies the rules if the rules are satified then call is reidtected to api server else call will be redirected to user saying status 429 too many calls. In case of any failures the requests will be stored in the queue and these request will be processed again once the issue is resolved.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
The Placement of rate limiter is key as the rate limiter cannot be placed at the client side because at client side it can easily be tempered and also it cannot be placed at the server side as synchronization will be an issue so we should place rate limiter in between the client and server like api gatteway . Different algorithms are present for rate limiting we will usse tocken bucket algorithm.
The request from the client will go to the load balancer and from the load balancer the call will go to the api gateway where the rate Limiter is presnt
The rate limiter first get the rules for the api from the redis cache and based on the ip address it generated a unique key then it again queries the redis back to check if the counter +1 statifies the rules if the rules are satified then call is reidtected to api server else call will be redirected to user saying status 429 too many calls. In case of any failures the requests will be stored in the queue and these request will be processed again once the issue is resolved.
Explain any trade offs you have made and why you made certain tech choices...
1) Using redis can be an expensive option but if we don't use redis and store the counter in the redis then the performance will suffered
2) The redis will be able to serve read in very less time
Try to discuss as many failure scenarios/bottlenecks as possible.
1) In case of failure the rate limiter will return status 500 and call will be placed in the queue once the issue is resolved the calll will then be again transfered to rate limiter from queue
2) We can use monitoring tools like prometheus for tracking the status of the application.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
1) As storing in redis can be expensive we can search for alternative option for storing these values.