Skip to content

Add ApplicationRateLimit for Group update API

Etienne Baqué requested to merge eb-implementation-of-application-rate-limiter into master

What does this MR do and why?

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/416705+

This MR adds a new application rate limit to control sending API calls to CustomersDot, whenever a group is updated.

The GitLab group update API can be used for many purposes (as explained in this comment). We want to avoid setting a new throttle at the API level just for the purpose of limiting the CustomersDot update of a namespace name - this would be too disruptive.

So the change that targets the CustomersDot update is twofold:

  1. The "non-blocking" increment of the new application rate limit, scoped to the targeted group ID.
  2. Right before sending a request to the CustomersDot namespace name change endpoint, we check that increment (Gitlab::ApplicationRateLimiter.peek)

In doing so, we're only limiting the number of requests sent to CustomersDot, which will address the initial problem raised in the related issue.

Screenshots or screen recordings

💻 Demo: https://www.youtube.com/watch?v=ci4FM2_jJHo

Context about proposed application rate limit

Metrics and context summary to bring SREs up to speed with this new limit have been posted in the description of the related issue, where I explain the rationale behind setting the limit to 120 per hour.

⚠ Despite the metrics and comments posted in the issue, this MR should be reviewed by an SREs, especially with regards to the introduction of this new ApplicationRateLimit on SM instances.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Etienne Baqué

Merge request reports