I would have to disagree with everyone saying B. B won't work if there are 2000 users registered and then a rate-limit of 2req/sec for each user. That would mean a cap on 1000 and the rest of the requests wouldn't be served. That's why we have RabbitMQ, which places the Request in a queue which workers handle when there is time. D is the right answer for this.

B. Seems the most sensible to me.

I'll go with B too: Explanation: When providing an API service, we need to ensure fair usage for every user so the system resources are serving everyone effectively and fairly. We need to apply restrictions to make sure that the majority of users are satisfied. The way to do that is to set a limit per user. For example, we can limit the number of requests per user to be no more than 100 per second.

Selected Answer: B I think B is the best answer here - rate-limit. Many APIs have built-in denial-of-service functionality that limits the number of requests per time interval, or they use throttling for some customer tiers (for example, one request per second for a free tier and unlimited for the paid one). You can use two approaches to handle rate-limiting restrictions for a specific API: - Send requests as usual. If an HTTP 429 response is received, pause (the duration may be hinted at in the response, depending on API) and then continue with a retry. - Find out API restrictions and limit the rate of your requests, which prevents an HTTP 429 error.

I will go with B. Since all Cisco API material and courses usually highlight how important rate limiting is: based on numbers of request, user actions, server traffic and concurrency.

What about C? A. Use algorithms like random early detection to deny excessive requests. Easy to discard, RED is a routing congestion avoidance mechanism. B. Set a per-user limit (for example, 5 requests/minute/user) and deny the requests from the users who have reached the limit. This would be a case of Token Bucket, but the Question does not mention the amount of users per second, so whatever we can think of here may not avoid hitting the platform below 1000 requests/second C. Only 1000 user connections are allowed; further connections are denied so that all connected users can be served. It seems to me a case of Sliding Window since it says the platform supports up to 1000 requests/second. That means when the app receives a new request it must check how many have been made in the last second; if 1000 have already been made the new request should be rejected. D. All requests are saved and processed one by one so that all users can be served eventually. Similar to option "B" the question does not mention that we have resources to queue requests.. This would be a case of Leaky Bucket where you also need to specify the capacity for queuing requests.

It totally depends on what kind of customers you have. You can have a waiting queue to serve users later. If it's a API there should be a rate-limit such as answer B implies. The API requestor can have a handler that does a re-try every x amount of seconds still serving every customer. If you want to make it customer friendly you apply the D rule. But that only works with GUI based users they will wait just as with ticket sales, that will not work for API requests.

Why not C?

Read the question, it is a design parameter, 1000 requests should be received, there is no requirement about limiting anything, it is D

Selected Answer: B B sounds partly correct, but everything else is just dumb. So B

I changed my mind... I think D would be more correct (but still dumb). The question gives a design constraint of Requests/Min. It doesn't say anything about security. IRL, we would actually do both things: have some sort of throttling mechanism per user as well as a global req/sec cap.

Selected Answer: B D is not a correct answer because usually you want to get a number of requests, see if you can aggregate them and then serve the users. C is about the user connections, not about the requests per second. A RED is an algorithm used in networking B makes the most sense and would satisfy the described requirement.

B is the right answer as throttling the requests is the best way to serve all users efficiently

either it could be A or C why not B - if i have 1000 customer and each customer requested 5 times, then it becomes 5000 session , but here we are talking about 1000 request/sec. why not D - what if a malicious attacker sends 2000 request , then the server will process one by one then it will become busy serving malicious attackers requests.

It says 1000 requests must be served per second, does not say to drop or limit the exceeding requests but from a design and a client/perspective would it not be nice to have all those requests processed eventually of course we are not taking into consideration any DOS or malicious attach, the question is just merely asking how would you design an app that can serve 1000 requests per second.

Logging all the session requests will time out and create a DDoS situation. It needs rate limiting.

You are assuming a queue is necessary. It was just an example for the rate limiting. All APIs should have reasonable rate limiting. A developer would want the API call to be declined rather than waiting an indeterminate amount of time for it to be finished.