Protect services with rate limiting

A rate limiter caps how many requests a client (by user, API key, or IP) can make in a period. It protects services from abuse and overload, enforces fair use and pricing tiers, and limits the blast radius of a buggy client. Rejected requests get HTTP 429 Too Many Requests, ideally with a Retry-After header.

• Fixed window counter: count requests per clock window (for example per minute). Simple and cheap, but a client can send a full limit at the end of one window and another at the start of the next - about 2× in a short span.
• Sliding window log: store each request’s timestamp and count those within the last window. Accurate, but memory grows with traffic.
• Sliding window counter: blend the current and previous window counts. A cheap, good approximation.
• Token bucket: a bucket holds up to capacity tokens and refills at a steady rate. Each request spends a token. Capacity sets the allowed burst; the refill rate sets the sustained throughput.

A worked example: with a limit of 3 per minute, requests at seconds 1, 2, 2, 3 and 3 give three allowed and two rejected. A request at second 61 falls in the next window, so it’s allowed.

With many API servers, each server’s local counter only sees part of the traffic. A distributed limiter keeps counters in a shared, fast store such as Redis, using atomic operations (INCR with an expiry, or a Lua script for a token bucket) so concurrent requests cannot race. Limiters usually live in an API gateway or middleware, and should fail open or closed deliberately if the store is unavailable.