Gateway rate limit mechanism clarification

[Renegade334]

The gateway section documents the send rate limit of 120 events per 60 seconds.

However, it's not documented exactly how that limit is implemented in practice, and since there's no rate limit information included in received gateway events (cf. REST API headers), this does leave end-users with a bit of a guessing game as to whether or not they're likely to overstep this limit with their next event:

• Does the limiter implement a rolling time window, such that it checks for 120 messages sent in the last 60 seconds prior to the current time?
• Does the limiter start a fixed 60-second window when it receives its first event, and reset immediately after that time window expires?
• Or does it do something different, like starting a new window when the time reaches a multiple of 60?

The penalty for overstepping the rate limit is for the API to completely close the websocket in response, but it's difficult for end-users to implement their own mitigation mechanisms when the way the gateway calculates the rate limit isn't documented. I'd advocate for this information being added to the gateway docs.

[erkinalp]

It is a fixed window limiter, with multiple limiting buckets depending on the route you use.

[erkinalp]

See #5144 #5557

[Renegade334]

Your answer refers to the REST API, not the websocket gateway.

[ckohen]

Further, the REST API no longer has a fixed window, it's a leaky bucket.