# hybrid quota-linear rate limiter

DevFeed: [hybrid quota-linear rate limiter](<https://devfeed.tech/articles/hybrid-quota-linear-rate-limiter-36226.md>)

Original publisher: [Read original article](<https://dotat.at/@/2026-01-12-hqlr.html>)

Published: 2026-01-13T00:12:01Z

Content type: article

Language: en

Sources: [Tony Finch's blog](<https://devfeed.tech/sources/tony-finch-s-blog.md>)

Topics: [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [Algorithms](<https://devfeed.tech/topics/algorithms.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [quotas](<https://devfeed.tech/tags/quotas.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>)

## AI overview

The article explores a hybrid quota-linear rate limiter intended to enforce request quotas more precisely within a time window while limiting storage costs and avoiding bursty client behavior. It compares linear rate limiting with fixed-window quota resets and notes trade-offs, including throttling response time and burstiness.

## Source excerpt

A while back I wrote about the linear rate limit algorithms leaky bucket and GCRA. Since then I have been vexed by how common it is to implement rate limiting using complicated and wasteful algorithms (for example). But linear (and exponential) rate limiters have a disadvantage: they can be slow to throttle clients whose request rate is above the limit but not super fast. And I just realised that this disadvantage can be unacceptable in some situations, when it's imperative that no more than some quota of requests is accepted within a window of time. In this article I'll explore a way to enforce rate limit quotas more precisely, without undue storage costs, and without encouraging clients to oscillate between bursts and pauses. However I'm not sure it's a good idea. linear reaction time fixed window quota resets hybrid quota-linear algorithm discussion opinion linear reaction time How many requests does a linear rate limiter allow before throttling? The parameters for a rate limiter are: q, the permitted quota of requests w, the accounting time window So the maximum permitted rate is q/w. Let's consider a client whose rate is some multiple a > 1 of the permitted rate (a for abuse factor) c = a * q/w I'll model the rate limiter as a token bucket which starts off with q tokens at time 0. The bucket accumulates tokens at the permitted rate and the client consumes them at its request rate. (It is capped at q tokens but we can ignore that detail when a > 1.) b(t) = q + t*q/w - t*a*q/w The time taken for n requests is t(n) = n/c = (n*w) / (a*q) After n requests the bucket contains b(n) = q + n/a - n The rate limter throttles the client when the bucket is empty. b(t) = 0 = q + t * (1 - a) * q/w 0 = 1 - t * (a - 1) / w t = w / (a - 1) b(n) = 0 = q + n * (1/a - 1) 0 = q - n * (a - 1) / a n = q * a / (a - 1) For example, if the client is running at twice the permitted rate, a=2, they will be allowed q*2 requests within w seconds before they are throttled. That's a bit slow. T