-
Notifications
You must be signed in to change notification settings - Fork 4
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
As a Open Data Hub maintainer I want a quota to limit the amount of historical data that can be requested in a single call #261
Comments
Implementation has already been done. |
Before defining any policies, we will first analyze the API logs and figure out which kinds of users are currently making historical data requests, and which ranges they request |
Limits have been disabled in test (can be configured by setting corresponding env variables in CI/CD) |
Decisions made on 11.04.2024: We will start with a quota limit of
According to the lo statistics, there seems to be only one elaboration type 3rd party application that is expected to be impacted immediately by this quota (parking prediction by Chris Mair).
|
Proposing production date: 11.09. |
In september we foresee to send out the next Community Update mail, what about communicating the change in the community email and put everything into production just after the communication? |
That's fine for me. I just needed a date to communicate to Chris, so we have an agreed deadline. We can postpone the actual release. Do you have a concrete date? |
@clezag we foresee to send out the community update the last week of september, probably the 24th or the 25th. |
@sseppi reminder for you: please notify Emily to include this point in the next community update. |
@rcavaliere Is alredy included in the text Emily presented at the last meeting. |
To prevent big queries that slow down or even bring our Mobility API down a quota that limits requests for more than a give time frame should receive a quota message, like we have for max requests per second.
To be fast, the implementation should be made to first introduce the limit and then implement the logic to allow bigger requests to certain users. So we implement the easy limit fast and the more complicated logic only if its really needed.
TODO:
@sseppi organize a dedicated meeting in the whole team, to discuss if this limits have any benefits or only through backs:
The text was updated successfully, but these errors were encountered: