Should the leaky bucket implementation should have timer-interrupt based implementation to leak the requests to be processed accurately? In current implementation it leaks at every new request, if the time gap b/w requests is huge that would lead to starvation of requests to be processed.
For token bucket alog especially java logic the bucket is getting filled according to milliseconds, but i have doubt for rate limiting, doesn't we have to set it at the end of the seconds?
If yes we are setting at the end of the second then this algorithm will fail when there are multiple requests and if the bucket didn't have enough tokens it should reject the request as there are no enough tokens and if time has elapsed it should refill the bucket. But in given code as we are filling the bucket each time services get requests even though it didn't have enough tokens.
we have to add below condition in refill function -
I think that your implementation of sliding window counter is not correct because of your calculation based on the following:
Window Transition Logic:
The logic moves to a new window if the elapsed time (timePassedInWindow) exceeds the windowSizeInSeconds.
If the elapsed time is much greater than the window size (size 15 seconds and elapsed time e.g.100 seconds), it effectively considers the last "previous window" as still valid. The previousWindowCount is updated with the currentWindowCount regardless of the gap.
Weighted Count:
The calculation combines a weighted count of the previous window and the current window. This includes the current window’s elapsed time and the proportion of the previous window that overlaps with the sliding window.
Handling Long Gaps:
When long gaps occur e.g. above 100 seconds between last and current request with 15 seconds window, the previous window’s count remains part of the calculation, even if its relevance has expired due to the large time gap.
love how readable and well it has been explained.
Nice post!!
Should the leaky bucket implementation should have timer-interrupt based implementation to leak the requests to be processed accurately? In current implementation it leaks at every new request, if the time gap b/w requests is huge that would lead to starvation of requests to be processed.
For token bucket alog especially java logic the bucket is getting filled according to milliseconds, but i have doubt for rate limiting, doesn't we have to set it at the end of the seconds?
If yes we are setting at the end of the second then this algorithm will fail when there are multiple requests and if the bucket didn't have enough tokens it should reject the request as there are no enough tokens and if time has elapsed it should refill the bucket. But in given code as we are filling the bucket each time services get requests even though it didn't have enough tokens.
we have to add below condition in refill function -
if (elapsedSecondFromLastRefill <= 0) {
System.out.println("No refill needed, elapsed seconds: " + elapsedSecondFromLastRefill);
return;
}
correct me if I am wrong?
I think that your implementation of sliding window counter is not correct because of your calculation based on the following:
Window Transition Logic:
The logic moves to a new window if the elapsed time (timePassedInWindow) exceeds the windowSizeInSeconds.
If the elapsed time is much greater than the window size (size 15 seconds and elapsed time e.g.100 seconds), it effectively considers the last "previous window" as still valid. The previousWindowCount is updated with the currentWindowCount regardless of the gap.
Weighted Count:
The calculation combines a weighted count of the previous window and the current window. This includes the current window’s elapsed time and the proportion of the previous window that overlaps with the sliding window.
Handling Long Gaps:
When long gaps occur e.g. above 100 seconds between last and current request with 15 seconds window, the previous window’s count remains part of the calculation, even if its relevance has expired due to the large time gap.