Hire Me
Architecture Pattern

Rate Limiter Comparison

Token Bucket vs Sliding Window vs Fixed Window — same requests, different decisions Fire request bursts and observe how each algorithm accepts or rejects them
Token Bucket
Tokens refill at constant rate · burst absorbing
Tokens 10 / 10
0Accepted
0Rejected
Accept rate
Sliding Window
Rolling 1-second window · smooth limiting
Window count 0 / 10
0Accepted
0Rejected
Accept rate
Fixed Window
Hard reset every second · boundary burst risk
Window count 0 / 10
0Accepted
0Rejected
Accept rate

About this demo

All three algorithms enforce the same limit — the same number of requests per second — but they differ in how they handle bursts and window boundaries. Token Bucket accumulates tokens at a fixed rate up to a maximum bucket size. Bursts are absorbed as long as tokens exist; requests are rejected only when the bucket is empty. This is the most burst-tolerant algorithm and is used by AWS API Gateway and most CDNs.

Sliding Window counts requests in a rolling time window. There is no burst allowance — the count simply tracks recent activity and rejects as soon as the limit is exceeded. It is smooth and predictable but slightly more expensive to implement (requires storing timestamps). Fixed Window resets a counter on a hard boundary every second. It is cheap to implement but susceptible to the boundary burst problem: a client can send the full limit at the end of one window and the full limit at the start of the next, receiving double the intended throughput at the boundary. Fire the burst at different timing to observe this effect.

Pattern: Rate Limiting · Token Bucket · Sliding Window · Fixed Window Technology: Java · Spring Boot · Resilience4j · Redis Read: Resilience Patterns in Spring Boot →