Exam 350-901 topic 1 question 6 discussion

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

B. Makes the most sense to me.

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: - Perform requests as normal. If an HTTP 429 response is received, make a 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, thus preventing an HTTP 429 error.

Logging all the sessions requests will timeout and create DDoS situation. It needs rate limiting.

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 achieve the described requirement.

B sounds partially correct, but everything else is simply dumb. So B

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 process 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 served 1000 requests per second.

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

Why not C??

It totaly depends what kind of customers you have. You can have a waiting que 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 friendely you apply the D rule. But that only work with GUI based users they will wait just as with ticket sales, that will not work for API requests.

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 talkng about 1000 request/sec. why not D - what if malicious attacker sends 2000 request , then server will process one by one then it will become busy in serving malicious attackers requests.

What about C? A. Use algorithms like random early detection to deny excessive requests. Easily discarded, 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 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 looks 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 mande 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" 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 queing requests.

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

B is the right answer as Throttling the requests is the best method to serve all users efficiently

I'll Go with B too: Explanation: When providing an API service, we need to ensure fair usage for every user so that the system resources are effectively and fairly serving all. We need to apply restrictions to make sure that all 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.