Which rate-limiting algorithm do you implement, and what's wrong with a fixed window?

The token bucket is favoured because it models what we actually want: let a user burst a little (they open a page and ten requests fire, which is normal) while capping the sustained rate. Bucket size is the permitted burst, refill rate is the sustained limit. Those two parameters express a policy that a single number can't.

The sliding window counter is a compromise worth knowing: keep two counters — the current window and the previous — and interpolate by how far into the current one you are. It removes the boundary hole at nearly fixed-window memory cost, and it's what many CDNs use. It's approximate rather than exact, but the error is far smaller than the cost of storing every timestamp.

The implementation detail people skip: the limit must be atomic across instances. Read-then-write to Redis from three machines lets more through than the limit. The correct shape is a Lua script executed atomically on Redis, or INCR with a conditional EXPIRE in one pipeline. And always return Retry-After with the 429 — a limit that doesn't say when to try again just makes clients try immediately.