Backend
Rate Limiting
Capping how many requests a client may make per window to defend against abuse, runaway costs and cascading overload — using token-bucket, leaky-bucket or sliding-window counters, usually in Redis. Return 429 with a Retry-After header. Key on user or API key rather than IP alone, since NAT and proxies make many users share an address.
Purpose
Rate limiting caps how many requests a client may make in a time window. It exists to protect a service from abuse, brute-force attacks, runaway bills and accidental overload, keeping it available for everyone else.
When to Use It
Login and OTP endpoints (anti-brute-force), public APIs (fair use and paid tiers), and any expensive operation such as search or model inference. It also shields downstream systems from traffic spikes.
Combine it with quotas for billing and with circuit breakers for resilience.
Trade-offs
Too strict and you block legitimate bursts; too loose and it fails to protect. Distributed limiting needs shared state (extra latency and a dependency), and keying only on IP unfairly lumps together users behind NAT or a corporate proxy.
Implementation
Use a token-bucket or sliding-window counter in a fast shared store like Redis, keyed on user or API key rather than IP alone. Return 429 Too Many Requests with a Retry-After header and rate-limit headers so well-behaved clients can back off.