Optimize Rate Limiting for Unleash feature flags API
Summary and Background
In gitlab-com/gl-infra/scalability#752 (closed) we've noticed that the feature flag API hits the unauthenticated rate limit in Rack::Attack.
Though this traffic isn't really "unauthenticated", we might want to consider adding a new Throttle for this type of request.
We've also noticed that some of these requests already get throttled in HAProxy. Should we look into which clients libaries are being used and see if they aren't misbehaving.
As part of gitlab-com/gl-infra&379 (closed) we'll be tightening rate limits on GitLab.com, so we'll be returning 429s for these requests slightly more often.
Problem to solve
Feature flag API calls, even though they are authenticated, are considered unauthenticated and run into the lower unauthenticated rate limits. Users have the need for higher rate limits so they can ensure their feature flags API calls they integrate into their applicatoins are serviced properly.
Proposal
The rate limit for the feature flag API was recently discussed in this issue. In short, what we can do today is to fix the rate limit to be taken into account as Authenticated Requests instead of Unauthenticated Requests. This gives 4x more capacity until users hit the limit, thus they can be more relaxed that it should be sufficient for small and medium sized infrastructure.
Documentation
Update rate limits documentation as needed
Available Tier
What does success look like, and how can we measure that?
Success is that users are able to make more Feature Flags beyond the existing unauthenticated limits. This can be measure by looking at feature flag API call rates after the feature is launched.
What is the type of buyer?
Is this a cross-stage feature?
No