Bảo MậtToken bucket cho phép bursts; sliding window không có burst issue của fixed window; dùng Redis-based implementation (Upstash) cho distributed deployment — in-memory rate limiter chỉ work trên single instance.
- Rate limiting ngăn abuse, brute-force, DoS. Fixed window: đếm requests trong window cố định (ví dụ 0:00-0:59, 1:00-1:59).
- Dễ implement, dễ bypass: gửi 100 req cuối window cũ + 100 req đầu window mới = 200 req trong 2 giây. Sliding window: track timestamps của requests trong rolling time window — không có burst issue của fixed window; cần store per-user timestamps trong Redis (sorted set).
ZADD key timestamp timestamp; ZREMRANGEBYSCORE key 0 (now-window); ZCARD keyđể đếm requests. Token bucket: user có bucket tokens, mỗi request tiêu 1 token, tokens được refill theo rate (1 token/giây). - Cho phép short bursts (bucket full = burst capacity) nhưng sustainable rate bị limit. Leaky bucket: requests vào queue, xử lý ở fixed rate — smooth output không có bursts; tốt cho APIs cần predictable throughput.
- Implementation:
@upstash/ratelimit(Redis-based, serverless-friendly);express-rate-limit(in-memory mặc định,rate-limit-redischo distributed);ioredis+ custom script. - Differentiated limits:
/api/auth/login(5 req/15min per IP),/api/*(100 req/min per user), public endpoints (1000 req/min). - Lưu ý: in-memory rate limiter không work trong multi-instance deployment — mỗi instance có counter riêng, limit thực tế là n×limit.
Token bucket allows bursts; sliding window avoids fixed window's burst issue; use a Redis-based implementation (Upstash) for distributed deployments — in-memory rate limiters only work on a single instance.
- Rate limiting prevents abuse, brute-force, and DoS attacks. Fixed window: counts requests in a fixed window (e.g., 0:00-0:59, 1:00-1:59).
- Easy to implement but easy to bypass: send 100 requests at the end of the old window + 100 at the start of the new one = 200 requests in 2 seconds. Sliding window: tracks request timestamps in a rolling time window — no burst issue; requires storing per-user timestamps in Redis (sorted set).
ZADD key timestamp timestamp; ZREMRANGEBYSCORE key 0 (now-window); ZCARD keyto count requests. Token bucket: users have a bucket of tokens; each request consumes 1 token; tokens refill at a fixed rate (1/second). - Allows short bursts (full bucket = burst capacity) but limits sustainable rate. Leaky bucket: requests enter a queue and are processed at a fixed rate — smooth output without bursts; good for APIs needing predictable throughput.
- Implementation:
@upstash/ratelimit(Redis-based, serverless-friendly);express-rate-limit(in-memory by default,rate-limit-redisfor distributed); custom Redis scripts with ioredis. - Differentiated limits:
/api/auth/login(5 req/15min per IP),/api/*(100 req/min per user), public endpoints (1000 req/min).
Pitfall: in-memory rate limiters don't work in multi-instance deployments — each instance has its own counter, so the real effective limit is n×limit.