Rate limiting strategies: Fixed window vs Sliding window vs Token bucket?

Rate limiting ngăn abuse, brute-force và DoS. Bốn thuật toán hay gặp:

Fixed window đếm request trong khung thời gian cố định (0:00-0:59, 1:00-1:59). Dễ làm nhưng dễ lách: gửi 100 request cuối window cũ cộng 100 request đầu window mới thành 200 request trong 2 giây.

Sliding window lưu timestamp của request trong một cửa sổ trượt nên không dính lỗ hổng trên; cần lưu timestamp theo user trong Redis sorted set:

ZADD key timestamp timestamp
ZREMRANGEBYSCORE key 0 (now-window)
ZCARD key

Token bucket cho mỗi user một bucket token, mỗi request tiêu 1 token, token refill theo tốc độ cố định (1 token/giây). Cho phép burst ngắn (bucket đầy = sức chứa burst) nhưng chặn được tốc độ trung bình.

Leaky bucket đẩy request vào hàng đợi và xử lý ở tốc độ cố định — output mượt, không burst; hợp với API cần throughput dự đoán được.

Thư viện: @upstash/ratelimit (nền Redis, hợp serverless), express-rate-limit (mặc định in-memory, thêm rate-limit-redis cho distributed), hoặc tự viết script với ioredis. Nên đặt hạn mức khác nhau theo route: /api/auth/login 5 req/15 phút mỗi IP, /api/* 100 req/phút mỗi user, endpoint public 1000 req/phút.

Lưu ý: rate limiter in-memory không dùng được khi deploy nhiều instance — mỗi instance đếm riêng nên hạn mức thực tế thành n×limit.