Rate Limiter Tester

Rate limiting restricts how many requests a client can make in a given time window. It protects APIs from abuse, prevents DDoS attacks, ensures fair usage among clients, and controls infrastructure costs. Common limits: 100 req/min for public APIs, 1000 req/min for authenticated users.

Token bucket maintains a bucket of tokens that refills at a constant rate (e.g., 10 tokens/min). Each request consumes one token. If the bucket is empty, the request is rejected. The bucket has a max capacity (burst size) that limits sudden spikes. It allows short bursts while enforcing a long-term average rate.

Sliding window tracks request timestamps within a rolling time window. Unlike fixed window, it doesn't reset at a set clock time — the window slides forward with each request. This prevents the boundary spike problem where clients double their rate by sending requests just before and after a window reset.

Fixed window divides time into discrete windows (e.g., each minute from :00 to :59). It counts requests in the current window and resets the counter at the window boundary. Simple to implement but vulnerable to boundary spikes: a client can send max_requests at :59 and again at :00 for 2x the intended rate.

429 Too Many Requests is the standard HTTP status code for rate limiting. APIs also typically include Retry-After header (seconds until the rate limit resets), X-RateLimit-Limit (max requests), X-RateLimit-Remaining (requests left in current window), and X-RateLimit-Reset (Unix timestamp of window reset).