Rate limiting strategies — token bucket vs sliding window

API needs rate limiting to prevent abuse, but choosing the wrong algorithm causes either too-strict limiting for legitimate users or gaps that allow bursts of abuse.

Choose based on use case: (1) Token bucket: allows bursts up to bucket size, refills at steady rate. Good for APIs where occasional bursts are OK. (2) Sliding window log: exact count over rolling time period. Most accurate but memory-heavy. (3) Sliding window counter: approximation using current + weighted previous window. Good balance of accuracy and efficiency. (4) Fixed window: simplest but allows 2x burst at window boundaries. Implementation: Redis INCR + EXPIRE for distributed systems. Headers to return: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After on 429.

Different algorithms make different tradeoffs between precision, memory usage, and burst tolerance. The right choice depends on your traffic patterns and abuse model.