Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quota-based throttling #1820

Open
1 task done
itzik-bd opened this issue Dec 31, 2023 · 0 comments
Open
1 task done

Quota-based throttling #1820

itzik-bd opened this issue Dec 31, 2023 · 0 comments

Comments

@itzik-bd
Copy link

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

We would like to be able to throttle based on quota from requests instead of 1 per request.

For example:

  • Lets say we have an API that gets a events: string[] as part of request body.
  • If rate limit is 100 events/min and we did 1st API call with 99 events
  • Then,
    • If we did 2nd API call with 2 events then it would throw rate-limit
    • If we did 2nd API call with 1 events then it would allow it

Describe the solution you'd like

In a similar way to the generateKey that can be overloaded, to have another method getQuota that decide the quantity that is being consumed, which by default would be 1 (i.e. 1 per API call)

Teachability, documentation, adoption, migration strategy

Since the default value would be 1, users will not have to change anything from their side.
Users that would like to implement quota based throttling would need to implement the getQuota inside the ThrottlerGuard and return the quota used in a single API request.

What is the motivation / use case for changing the behavior?

We would like to implement rate limit by events - similar to what AWS does for SNS (docs):

The messages per second quota is based on the number of messages published to an Amazon SNS region, combining Publish and PublishBatch API requests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant