A developer checks the performance of a web application. The application is in the local data center and uses a REST-based API. Based on the API logs, it is discovered that many its abandon API requests. Also, the response is taking too long to get back. What is the reason for this issue?

API logs that show numerous client-abandoned requests together with long response times normally indicate server saturation. When no rate-limiting exists, clients can issue an unbounded number of concurrent requests. The back-end threads, sockets, and database connections become exhausted, queue lengths grow, and latency rises until clients time-out and drop the requests. Implementing rate limiting (e.g., requests-per-second quotas or token buckets) protects resources, keeps queue depth manageable, and maintains predictable response time. Pagination controls payload size per request, but does not stop request floods; authentication settings have negligible impact on aggregate latency.

A. Pagination is not implemented – Increases payload size per request but does not create the high concurrency that produces wide-spread time-outs and abandoned calls.
B. Token-based authentication is enabled – Adds only milliseconds of verification; does not by itself cause sustained high latency or mass request drops.
D. Token-based authentication is disabled – Lack of tokens has no causal link to slow responses or abandoned requests; it simply removes an auth step.

1. Cisco DevNet, “API Design and Fundamentals – Rate Limiting,” Section “Why rate limiting matters,” paras. 2-4 (developer.cisco.com/docs/api-design/#rate-limiting)

2. Cisco AppDynamics Whitepaper, “REST API Performance Best Practices,” p. 7, “Prevent overload with rate limits.”

3. IETF RFC 6585, §4, “429 Too Many Requests,” explains server overload when excessive requests are not limited.

4. MIT 6.824 Distributed Systems, Lecture “Scalability: Overload control,” slides 8-9, discuss request throttling to keep latency bounded.