SRS-003 The REST API implements rate limiting to prevent abuse

Category

• Functional

Importance

• High

Description

Rate limiting is a mechanism to control the number of requests a client can make to the server within a specified time frame. It is essential for maintaining the stability and availability of the API, especially under conditions where multiple clients may make simultaneous or excessive requests. By setting rate limits, we can ensure everyone gets fair access, guard against abuse, and keep the server from being overloaded by too many requests from a single source.

Rate limiting should be flexible so we can configure different thresholds for various clients or endpoints. For example, we might impose stricter limits on anonymous users compared to authenticated ones, or adjust limits based on how sensitive or resource-intensive are the API endpoints being accessed.

The implementation should provide meaningful feedback to clients when their requests exceed the rate limit, such as returning an HTTP 429 Too Many Requests status code along with a message indicating the nature of the rate limit and when the client can retry their request. Additionally, detailed logging and monitoring should be in place to track rate limit violations and support troubleshooting and analysis of client behaviors.

To accommodate various use cases and ensure robustness, the rate limiting mechanism could employ algorithms such as the fixed window, sliding window, or token bucket. Each of these approaches has its own advantages and trade-offs in terms of precision and resource utilization.

Activities generated

• Define the rate limiting policies (e.g., maximum requests per minute/hour).
• Implement rate limiting logic in the API (or on a reverse proxy server in front of the API).
• Monitor and log rate limiting metrics.
• Update API documentation to include rate limiting details.

Implements user needs

This requirement ensures the API remains available and responsive for all users by preventing any single user or client from consuming disproportionate resources.

Causes failure modes

• Misconfigured rate limits leading to legitimate users being blocked.
• Insufficient rate limits allowing abuse to continue.
• Overly strict limits impacting user experience negatively.

Tested by software tests

• PLAN_007: Rate limiting for anonymous users
• PLAN_008: Rate limiting for authenticated users
• PLAN_009: Logging and monitoring of rate limit violations

Implements risk control measures

• Mitigate the risk of distributed denial-of-service (DDoS) attacks.
• Ensure equitable resource distribution among users.

Acceptance criteria

• The API rejects requests exceeding the rate limit with a clear error message.
• Rate limiting parameters are configurable.
• Logs accurately reflect rate limit violations and actions taken.

Constraints

There are no particular constraints for this requirement.

Dependencies

• Implemented an authentication service to verify client identities.
• Logging and monitoring infrastructure to track rate limit metrics

Performance considerations

• Rate limiting logic does not significantly degrade API performance.

Additional notes

In the future, we might consider using a sliding window or token bucket algorithm for rate limiting.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: JD-004, JD-005, JD-009, JD-017
• Approver: JD-003