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

Ability to control RateLimiter start time #252

Open
jonasmalacofilho opened this issue Dec 8, 2024 · 0 comments
Open

Ability to control RateLimiter start time #252

jonasmalacofilho opened this issue Dec 8, 2024 · 0 comments

Comments

@jonasmalacofilho
Copy link
Contributor

jonasmalacofilho commented Dec 8, 2024

Hi Andreas,

I've been working on a distributed rate limiter based on governor. GCRA is particularly well suited for this, I think, since the only state that needs to be stored is the TAT.

I've implemented a StateStore backed by Redis/ValKey, where the CAS loop uses a simple WATCH/MULTI/EXEC transaction pattern. Of course, the same quota settings, underlying state store and a common (wall or otherwise) clock must be used by all nodes for this to work correctly.

Additionally, one issue I found is that a governor RateLimiter records the TATs relative to the time it was created (according to the specified clock), and there's no good way to influence this. This is a problem because, in the distributed rate limiter scenario, multiple RateLimiters (started at different times) need to agree on the meaning of any TAT retrieved from or stored to the backing store.

The workaround for this I'm using is to implement a clock that lies on the first invocation to now(), but it's a fragile hack and I would like to add some first-party support for this use case to governor.

The simplest alternative would be to add a new associated function to RateLimiter that allows the caller to specify the start time. Alternatively, a new epoch() method could be added to the Clock trait, or to a new trait that has the former as supertrait.

Ideally, though, it would be nice to have some way to tie a state store that depends on shareable clocks with the clock type used in the rate limiter. But it's not immediately obvious to me how this could be done without breaking changes.

Would any of above alternatives be acceptable additions to governor? And/or do you have any other thoughts on this?


By the way, the clock I'm using is based on SystemClock. Assuming NTP has been configured on the host, its precision is sufficient for the applications I have in mind for these distributed rate limiters, which all involve rate limiting attempts per user at certain sensitive auth operations.

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