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

[request] Multiple ratelimiting options per API #205

Closed
tamizhgeek opened this issue May 7, 2015 · 12 comments
Closed

[request] Multiple ratelimiting options per API #205

tamizhgeek opened this issue May 7, 2015 · 12 comments
Assignees
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.
Milestone

Comments

@tamizhgeek
Copy link
Contributor

Here is our usecase:

For an API, we impose a monthly limit of 100,000 calls. Also there is a second level throttling of 5 requests/second to avoid too many concurrent requests. Currently, this is not possible with kong.

I think we can allow to have multiple rate limits per API provided they have different period values. And while throttling the requests, we can verify all of them and throw a 429 even if any one has crossed the quota. I would like a send a PR to fix this. But, before I would like to have the feedback.

Thanks!

@thibaultcha
Copy link
Member

👍 for the feature, and for the PR, we would love to see some contributions ;)

@thibaultcha thibaultcha changed the title [request/review] Multiple ratelimiting options per API [request] Multiple ratelimiting options per API May 7, 2015
@melihmucuk
Copy link

+1

@thibaultcha thibaultcha added the idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports. label May 7, 2015
@sonicaghi
Copy link
Member

+1

@tamizhgeek
Copy link
Contributor Author

Thanks for the 👍

Currently the rate limiting config is like:

--data "value.limit=100" and --data "value.period=hour"

There are two ways I can think of supporting multiple configurations.

  1. --data "value.limits=5,1000" and --data "value.periods=second,hour" (Having limit and periods as separate options and rely on the order supplied by the user to match them).
  2. --data "value.limits=5:second, 1000:hour" (Much cleaner, but removing a existing option from API)

which one do you guys prefer?

@thibaultcha
Copy link
Member

I think the second solution is much cleaner, it sounds great.

@sonicaghi
Copy link
Member

note: these kind of plugins are currently "per API" only, but in the very near future will be and should be per endpoint too.

@tamizhgeek
Copy link
Contributor Author

@sinzone Agreed., this addition wouldn't stand in the way of supporting per endpoint level configs.

@subnetmarco
Copy link
Member

I like option 2, but with the key=value pairs inverted like second:5, hour:10.

This is because we are using Lua tables internally so having the same limit for different period wouldn't be possible and the last one would override the previous ones, for example if we had 5:second, 5:hour then 5:hour would be the only one available since the unique key 5 is being used two times.

@thibaultcha
Copy link
Member

That's just a matter of how you parse them.

@tamizhgeek
Copy link
Contributor Author

PR for documentation/website change is here : https://github.com/ind9/getkong.org/pull/1

@lucamaraschi
Copy link

👍

@subnetmarco
Copy link
Member

Closed with #382.

hutchic added a commit that referenced this issue Jun 10, 2022
* test(go) ability to test GO

* chore(ci) test against next as the default in CI

* chore(ci) add a retry

* chore(ci) only retry the Ubuntu stage
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.
Projects
None yet
Development

No branches or pull requests

6 participants