api-rate-limitinglisted

## When to Use - Use when: an endpoint is abused by bots or runaway clients - Use when: implementing API quotas for a SaaS product (free vs paid tiers) - Use when: protecting expensive endpoints (AI inference, file export, email send) - Use when: a DB query spikes because one client sends 1000 req/s - Do NOT use for: DDoS mitigation at scale — use a WAF or CDN rate limiting - Do NOT use for: queue-based job throttling — use a job queue with concurrency limits --- ## Algorithm Comparison | Algorithm | Burst allowed? | Memory | Precision | Use when | |---|---|---|---|---| | **Fixed window** | Yes (at boundary) | O(1) | Low | Simple counters; acceptable boundary spike | | **Sliding window log** | No | O(requests) | High | Strict fairness; low traffic | | **Sliding window counter** | Partial | O(1) | Medium | Best default — accurate, memory-efficient | | **Token bucket** | Yes (controlled) | O(1) | High | APIs that allow short bursts | | **Leaky bucket** | No | O(1) | High | Smooth output rate (e.g., email sending) | **Default recommendation: sliding window counter** for most API endpoints. Use **token bucket** when legitimate clients need burst capacity (SDK retries, batch uploads). --- ## Sliding Window Counter (Redis) ```js import Redis from 'ioredis'; const redis = new Redis(process.env.REDIS_URL); async function slidingWindowRateLimit(key, limit, windowSeconds) { const now = Date.now(); const windowStart = now - windowSeconds * 1000; const pipeline = redis.pi