-
Notifications
You must be signed in to change notification settings - Fork 458
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
Post-request Reporting of hits_addend
#636
Comments
Actually, I don't think we need another method for this other than Request -> Envoy If all done in Envoy, there may be some kind of "local acceptable margin of error/overage" we could encode as well 🤔 |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
help wanted 🙏🏼 |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
help wanted – is there a better place to move this question? |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
When implementing general quota usage metering and limiting of I/O applications (like databases), the cost of each request is not known ahead of time. Adding the ability to report the request's usage (
hits_addend
) after the request has been processed would allow more flexible rate-limiting use cases such as these.I don't know if it would make sense to modify the RLS v3 API, but could essentially extend it in this service with:
Request -> Server
Server -> Rate Limit Service (ShouldRateLimit
hits_addend
= 0)Server -> DB (calculate cost)
Server -> Rate Limit Service (ReportUsage
hits_addend
=cost
)Server -> Response based on RateLimitResponse
Using the same Request and Response objects would allow also the caller to choose whether to enforce the limit consistently or trade performance and report the usage async of sending the response.
If something like a standard header for specifying hits (envoyproxy/envoy#34184) gets added to envoy, we could also consider upstreaming this to the RLS API and supporting the same header on responses for reporting cost.
The text was updated successfully, but these errors were encountered: