I think it's a good idea to use the tested implementation. Thanks for the proposal.
Yufei On Wed, Jan 21, 2026 at 6:48 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi All, > > +1 to all points raised by Robert. > > Re: monotonic clock, I believe it can certainly help with the rate limiter > impl. logic, but it will not help with determinism in runtime, because even > a monotonic clock may not advance uniformly compared to physical time. > > Re: Guava's RateLimiter vs. Quarkus Bucket4J, I do not have any > experience with either of these, but a Quarkus-native option sounds > interesting to me. At least I think it's worth exploring deeper to see how > it could be integrated into Polaris from a practical perspective. > > Cheers, > Dmitri. > > On Wed, Jan 21, 2026 at 6:25 AM Alexandre Dutra <[email protected]> wrote: > > > Hi Robert, > > > > I fully support the idea of leveraging existing battle-tested > > libraries, particularly for complex algorithms like the token bucket, > > which deals with time and a multitude of potential edge cases. > > > > Guava's RateLimiter seems like a simple and straightforward choice, > > given that Guava is already present in Polaris. > > > > For completeness, I'd also mention the Quarkus Bucket4J extension [1]. > > It uses the Bucket4J library [2]. It can do a lot more things (e.g. > > distributed bucketing, or more advanced token limits). I did some > > research a while ago and although they seem to require the buckets to > > be known at build time [3], in fact I think we could leverage what > > they call "population segmentation" [4] to achieve per-realm > > bucketing. > > > > Guava is likely more than enough for our use case, but if we want more > > tight integration with Quarkus, the Bucket4J extension could be > > considered as well. > > > > Thanks, > > Alex > > > > [1]: https://docs.quarkiverse.io/quarkus-bucket4j/dev/index.html > > [2]: https://github.com/bucket4j/bucket4j > > [3]: https://github.com/quarkiverse/quarkus-bucket4j/issues/173 > > [4]: > > > https://docs.quarkiverse.io/quarkus-bucket4j/dev/index.html#_population_segmentation > > > > On Wed, Jan 21, 2026 at 9:42 AM Robert Stupp <[email protected]> wrote: > > > > > > Hi all, > > > > > > Rate limiting was introduced to Polaris in September 2024 and has seen > > > several updates since. Recently, a bug was identified regarding how we > > > handle certain logic paths, and a fix has been proposed in a new PR. > > > > > > In reviewing the recent PR and the underlying implementation, I’ve > > > been thinking about a few architectural questions: > > > > > > 1. Correctness and Determinism: > > > Does the current logic fully capture the deterministic properties > > > required by the Token Bucket algorithm? For instance, by not > > > accounting for fractional token regeneration, are we at risk of > > > drifting from expected behavior? > > > > > > 2. Testing Strategy: > > > Would it be beneficial to introduce deterministic clock simulations or > > > property-based verification to our test suite? I’m concerned that our > > > current reliance on the wall clock might make it difficult to catch > > > edge cases in a CI environment. > > > > > > 3. Clock Sources: > > > Since the wall clock can move backward and forward, should we consider > > > moving toward a strictly monotonic clock to avoid arithmetic overflows > > > or "infinite token" scenarios? > > > > > > 4. Leveraging Existing Libraries: > > > Given the complexity of getting concurrency and synchronization right > > > for high-throughput rate limiting, would it make sense to explore > > > using Guava’s RateLimiter? Since it's already on our classpath, could > > > we benefit from its maturity, optimized synchronization and > > > sub-millisecond precision? > > > > > > I'm also curious to hear your thoughts on whether we should address > > > these additional areas: > > > * Cold Start: Should we be supporting "warm-up" periods for rate > > limiters? > > > * Contention: Could we reduce synchronization overhead by leveraging a > > > more mature implementation's critical paths? > > > > > > Rather than continuing to patch the custom implementation, what do you > > > all think about pausing the development on TokenBucket and evaluating > > > a migration to a more established library like Guava? > > > > > > Robert > > >
