Rate-limiting mathematics: rates, windows, and GCRA

If L requests are allowed during a time window W, the average allowed rate is L divided by W. For example, 100 requests per 60 seconds is about 1.67 requests per second.

In Token Bucket, tokens arrive at a refill rate and each request consumes tokens according to its cost. Bucket capacity controls how much burst traffic can be absorbed at once.

• rate: token generation speed
• capacity: maximum stored tokens
• cost: logical request cost
• remaining: available token budget

GCRA tracks a theoretical arrival time instead of simply counting requests. For limit L over window W, the base interval and burst tolerance follow these relationships.

For L=100 and W=60s, the base interval is 0.6 seconds. The burst-tolerance quantity from this formula is 0.6×99 = 59.4 seconds. This timing quantity is not the same thing as Token Bucket capacity.

In a distributed system, the meaning of rate and time must be explicit: what is counted, which clock is used, and what decision is returned near the limit. These are part of system semantics.

RateLimitEngine implements Fixed Window, Sliding Window, Token Bucket, and GCRA, using Redis server time and atomic transitions for distributed state. It is a direct example of turning mathematical behavior into an engineering contract.

• Compute the average rate for 60 requests in 30 seconds.
• Explain the difference between Token Bucket capacity and GCRA burst tolerance.
• If one request costs 5 permits, what happens to remaining capacity?