One of the API reliability scenarios I tested was validating the system’s throttle limit based on a business rule that allows a maximum of 60 requests per minute per client. The objective was to ensure that the API could handle requests within the defined limit while preventing excessive traffic that could potentially impact system stability and performance.
The test was performed by sending a controlled number of requests within a one-minute window. I validated the behavior at several boundaries, including 59 requests, exactly 60 requests, and more than 60 requests within the same period. The expected behavior was that requests up to the defined limit would be processed successfully, while requests exceeding the limit would be rejected with the appropriate HTTP status, such as 429 Too Many Requests, and a clear error response.
I also verified the behavior when the throttle window expired by waiting until the next rate-limit window and sending requests again. This was important to confirm that the limit was applied based on the intended time window rather than permanently blocking the client after reaching the threshold.
From a QA perspective, the validation focused not only on whether the API returned the correct response, but also on boundary conditions, consistency of enforcement, response headers, retry behavior, and isolation between clients. For example, reaching the 60-request limit from one client should not unintentionally prevent another client from accessing the API.
Example Test Scenario
| Scenario | Request Count | Expected Result |
|---|---|---|
| Below limit | 59 requests/min | All requests accepted |
| At limit | 60 requests/min | All requests accepted |
| Exceed limit | 61+ requests/min | Excess requests rejected with 429 |
| New window | After 1 minute | Requests accepted again |
| Multiple clients | 60 requests/client | Limits enforced independently |
Conclusion
The API was able to enforce the 60 requests per minute limit as expected. Requests within the limit were accepted, while requests above the limit returned 429 Too Many Requests.
For the testing, I used Locust to generate and control the API requests. In some cases, I also used JMeter, especially when I needed to simulate different request patterns or concurrent traffic.