Fixed window rate limiting
Fixed window rate limiting counts requests in discrete, non-overlapping time buckets (e.g., every minute, every hour). When the window resets, the counter goes back to zero regardless of when requests arrived in the previous window. This creates the "burst at the boundary" problem: a client can send the full limit at 23:59:59 and again at 00:00:01, effectively doubling their rate for a brief period.
Formula
window_size = configured_time_period. request_count = requests_in_window. if request_count > limit: reject_request.Why it matters in practice
Fixed window is simple to implement and understand, making it popular for basic rate limiting. However, the burst-at-boundary problem means it can be circumvented by timing requests at window edges. For APIs that need to protect against sophisticated abuse, sliding window or token bucket algorithms provide better protection. Fixed window is still useful for non-security rate limiting where occasional bursts are acceptable.
Common mistakes
- •Using fixed window for security-critical rate limiting — attackers can exploit the burst-at-boundary behavior.
- •Setting window sizes too small (sub-second) — this creates high-frequency counter resets and can be expensive to implement at scale.
- •Not considering time zone handling in distributed systems — ensure all servers use UTC or a synchronized time source.