Skip to content

Implement rate limits for Tenant Scale endpoints

Description

After Investigate rate limits for Tenant Scale endpoints (#421905 - closed) and Deprecation notice of rate limits for Tenant Sc... (#421908 - closed), we should implement the limits.

Note: If the request is unauthenticated and the endpoint could be accessed without authentication and not already rate-limited then the endpoint will be rate-limited by IP and it will have the same value as for the rate-limiting by the user.

Endpoint Rate limit per user
GET /api/v4/users/:user_id/projects 300 requests per minute
GET /api/v4/users/:user_id/contributed_projects 100 requests per minute
GET /api/v4/users/:user_id/starred_projects 100 requests per minute
GET /api/v4/projects 2000 requests per 10 minutes
GET /api/v4/groups/:id/projects 600 requests per minute
GET /api/v4/projects/:id 400 requests per minute
GET /api/v4/groups 200 requests per minute
GET /api/v4/groups/:id 400 requests per minute

Implementation guide

  1. Use check_rate_limit! and configure the limits on lib/gitlab/application_rate_limiter.rb. Examples: !77119 (merged), !118296 (merged).
  2. Use this scope: current_user || ip. So we can rate-limit based on user for authenticated requests and based on IP for unauthenticated requests. We can use the same value for both IP and user. See this comment for more info #421905 (comment 1832435121).
  3. Use the rate limits defined in the above table.
  4. Use a feature flag and the brownout technique mentioned here #451173 (comment 1832114452) to roll out this change.
  5. Add an application setting to configure it and to allow self-managed instances to have their own limits.
  6. Consider getting a review from @reprazent on the MR.
Edited by Abdul Wadood