Bạn thiết kế rate limiting như thế nào?

Question

Accepted Answer

**Rate limiting** giới hạn số request mà một client có thể thực hiện trong một cửa sổ thời gian — bảo vệ hệ thống khỏi lạm dụng, quá tải, và đảm bảo sử dụng công bằng. Đây là một thành phần system design phổ biến, với nhiều thuật toán và cân nhắc.

## Tại sao rate limiting

```text
✓ BẢO VỆ khỏi lạm dụng → ngăn tấn công (brute force, scraping, DoS), sử dụng quá mức
✓ NGĂN QUÁ TẢI → bảo vệ hệ thống khỏi bị quá tải (ổn định)
✓ SỬ DỤNG CÔNG BẰNG → đảm bảo không client nào độc chiếm tài nguyên; giới hạn theo tier (free vs paid)
✓ Kiểm soát COST; bảo vệ service downstream
→ một yêu cầu phổ biến cho API và service.
```

## Các thuật toán rate limiting

```text
FIXED WINDOW → đếm request mỗi cửa sổ thời gian cố định (vd 100/phút); đơn giản
  ✗ cho phép bùng nổ ở ranh giới cửa sổ (lên tới 2x ở các mép)
SLIDING WINDOW → cửa sổ thời gian trượt → mượt hơn, không bùng nổ ở ranh giới (chính xác hơn)
TOKEN BUCKET → token nạp lại theo một tốc độ; mỗi request lấy một token → cho phép BÙNG NỔ lên tới
  kích thước bucket trong khi giới hạn tốc độ trung bình (phổ biến, linh hoạt)
LEAKY BUCKET → request được xử lý theo tốc độ đều đặn (làm mượt đầu ra)
```

## Cân nhắc triển khai

```text
✓ DISTRIBUTED → giới hạn phải được chia sẻ qua các server → dùng một kho tập trung (REDIS
  phổ biến: counter atomic, nhanh, chia sẻ qua các instance)
✓ Xác định client → theo API key, user ID, IP
✓ Trả về phản hồi rõ ràng → HTTP 429 (Too Many Requests); kèm header limit/retry-after
✓ Ở đâu → tại API gateway, load balancer, hoặc lớp application
✓ Độ chi tiết → theo user, theo endpoint, toàn cục; các tier/giới hạn khác nhau
```

## Tại sao điều này quan trọng

Hiểu cách thiết kế rate limiting là giá trị vì nó là một **thành phần system design phổ biến** để bảo vệ hệ thống và đảm bảo sử dụng công bằng, nên đây là kiến thức thực tế quan trọng.

Rate limiting — giới hạn số request một client có thể thực hiện trong một cửa sổ thời gian — giải quyết các nhu cầu quan trọng: **bảo vệ khỏi lạm dụng** (ngăn tấn công như brute force, scraping và DoS), **ngăn quá tải** (bảo vệ sự ổn định hệ thống), đảm bảo **sử dụng công bằng** (không client nào độc chiếm tài nguyên, hỗ trợ giới hạn theo tier như free vs paid), và kiểm soát chi phí.

Những điều này khiến rate limiting là một yêu cầu phổ biến cho API và service.

Hiểu các **thuật toán** cùng trade-off của chúng — **fixed window** (đơn giản nhưng cho phép bùng nổ ở ranh giới), **sliding window** (mượt hơn và chính xác hơn), **token bucket** (cho phép bùng nổ có kiểm soát trong khi giới hạn tốc độ trung bình — phổ biến và linh hoạt), và leaky bucket (làm mượt đầu ra) — là kiến thức thiết kế then chốt, vì chọn thuật toán đúng ảnh hưởng đến hành vi.

Hiểu các **cân nhắc triển khai** đặc biệt quan trọng: xử lý **rate limiting phân tán** (giới hạn chia sẻ qua nhiều server, thường dùng **Redis** cho counter atomic nhanh chia sẻ qua các instance — vì giới hạn theo từng server không hoạt động trong distributed system), xác định client (theo API key, user, hoặc IP), trả về phản hồi rõ ràng (HTTP 429 với header retry-after), chọn nơi áp dụng (gateway, load balancer, hoặc application), và độ chi tiết (theo user, theo endpoint, theo tier).

Những điều này phản ánh thiết kế rate limiting hoạt động được trong distributed system thực.

Rate limiting là một thành phần thường cần đến, thường xuất hiện trong các thảo luận system design và phỏng vấn.

Vì rate limiting là một thành phần phổ biến, quan trọng để bảo vệ hệ thống (khỏi lạm dụng và quá tải) và đảm bảo sử dụng công bằng, và vì hiểu các thuật toán, trade-off của chúng, và đặc biệt là triển khai phân tán (giới hạn chia sẻ qua Redis) là quan trọng để thiết kế nó tốt, nên hiểu cách thiết kế rate limiting là kiến thức system design có giá trị, liên quan thực tế — một thành phần phổ biến để bảo vệ service và đảm bảo sử dụng công bằng, đòi hỏi hiểu các thuật toán và triển khai phân tán, và là một chủ đề thường được thảo luận trong system design để xây dựng hệ thống vững chắc, được bảo vệ.