Chương 27. Rate Limit Và Quota

Ở chương 25, ta nói về concurrency:

> Có bao nhiêu job đang chạy cùng lúc?

Ở chương 26, ta nói về retry:

> Khi lỗi tạm thời, thử lại thế nào cho không phá dữ liệu?

Chương này nói về một vấn đề rất thực tế khi hệ thống gọi API bên ngoài:

> Ta được phép gọi bao nhiêu, gọi nhanh đến mức nào, và làm sao không vượt giới hạn?

Đó là câu chuyện của rate limit và quota.

Ví dụ AI Judge:

Gemini API có thể cho:

100 requests/phút

Nhưng nếu worker của ta tăng concurrency lên cao, cộng thêm retry, hệ thống có thể vượt giới hạn rất nhanh.

Khi đó provider trả:

429 Too Many Requests

hoặc chặn tạm thời.

Rate limit không chỉ là chuyện "API bên kia khó tính".

Nó là cách bảo vệ:

Provider.
Hệ thống của ta.
Database.
Chi phí.
Công bằng giữa user/tenant.

---

27.1. Rate limit là gì?

Rate limit là giới hạn tốc độ sử dụng trong một khoảng thời gian.

Ví dụ:

100 requests/phút
10 requests/giây
1.000 requests/giờ
50.000 tokens/phút

Rate limit trả lời câu hỏi:

> Trong một khoảng thời gian, được làm tối đa bao nhiêu lần?

Ví dụ:

Gemini API: 100 request/phút
Email provider: 1.000 email/phút
Payment API: 50 request/giây
Internal API: 500 request/phút/service

Nếu vượt, hệ thống có thể nhận:

429 Too Many Requests

hoặc lỗi tương tự.

---

27.2. Quota là gì?

Quota là giới hạn tổng lượng sử dụng trong một kỳ hoặc phạm vi.

Ví dụ:

1.000.000 tokens/ngày
10.000 bài chấm/tháng
100GB bandwidth/tháng
5.000 email/ngày

Quota trả lời câu hỏi:

> Tổng cộng được dùng bao nhiêu?

Rate limit giống tốc độ chạy trên đường.

Quota giống bình xăng hoặc ngân sách trong ngày/tháng.

Bạn có thể không chạy quá tốc độ, nhưng vẫn hết xăng nếu đi quá nhiều.

Trong AI:

Rate limit có thể là requests/phút.
Quota có thể là tokens/ngày hoặc tiền/ngày.

Cần quản lý cả hai.

---

27.3. Concurrency, rate limit và quota khác nhau thế nào?

Ba khái niệm này rất dễ lẫn.

Concurrency

Bao nhiêu request/job đang chạy cùng lúc?

Ví dụ:

150 request Gemini đang bay.

Rate limit

Bao nhiêu request được bắt đầu trong một khoảng thời gian?

Ví dụ:

100 request/phút.

Quota

Tổng cộng được dùng bao nhiêu trong một kỳ?

Ví dụ:

1 triệu tokens/ngày.

Một câu nhớ:

> Concurrency là số đang chạy. Rate limit là tốc độ bắt đầu. Quota là tổng ngân sách.

---

27.4. Ví dụ AI Judge: 90 giây và 100 RPM

Giả sử:

Mỗi bài chấm mất 90 giây.
Provider cho 100 requests/phút.

Muốn dùng gần 100 requests/phút, concurrency cần khoảng:

100/phút = 1.67 request/giây
1.67 * 90 ≈ 150 request đang chạy cùng lúc

Nhưng nếu set concurrency = 150 mà không có rate limiter, hệ thống có thể bắt đầu request quá nhanh.

Ví dụ queue đang có 10.000 job.

Worker vừa khởi động 150 slot.

Nó có thể bắn một đợt lớn request ngay lập tức.

Nếu retry cũng xảy ra, số request càng khó kiểm soát.

Vì vậy cần:

Concurrency limit: tối đa bao nhiêu request đang bay.
Rate limiter: tối đa bao nhiêu request bắt đầu mỗi phút.
Quota guard: tổng token/cost mỗi ngày.

Ba lớp này bổ sung cho nhau.

---

27.5. Vì sao concurrency cao có thể vượt rate limit?

Concurrency cao không tự động vượt rate limit.

Nhưng nó làm khả năng vượt cao hơn nếu không kiểm soát tốc độ.

Ví dụ:

Mỗi request mất 1 giây.

Concurrency 100 nghĩa là có thể hoàn thành khoảng:

100 request/giây
= 6.000 request/phút

Nếu provider chỉ cho 100 request/phút, chắc chắn vượt.

Nhưng nếu mỗi request mất 90 giây:

Concurrency 100 cho throughput lý thuyết:

100 / 90 giây = 1.11 request/giây
= 66.7 request/phút

Chưa vượt 100 RPM.

Vì vậy phải nhìn cả:

Concurrency.
Latency.
Throughput.
Rate limit.

Không thể chỉ nhìn một con số.

---

27.6. Vì sao retry có thể vượt rate limit?

Retry làm tăng số request thật.

Ví dụ:

Bạn có 100 job.

Mỗi job gọi API một lần.

Nếu 20 job timeout và retry 2 lần:

100 request ban đầu
40 request retry
= 140 request

Nếu provider đang chậm, nhiều job có thể cùng timeout và cùng retry.

Khi đó dễ tạo retry storm.

Vì vậy retry phải đi cùng:

Backoff.
Jitter.
Rate limiter.
Circuit breaker nếu cần.
Giới hạn retry.

Không có rate limiter, retry có thể biến lỗi nhỏ thành vượt quota lớn.

---

27.7. Rate limiter là gì?

Rate limiter là cơ chế giới hạn tốc độ.

Ví dụ:

Chỉ cho bắt đầu tối đa 90 request Gemini mỗi phút.

Nếu job muốn gọi API nhưng đã hết slot trong phút này, nó phải:

Chờ.
Requeue.
Retry sau.
Hoặc fail có kiểm soát tùy nghiệp vụ.

Rate limiter giống nhân viên gác cổng:

Mỗi phút chỉ cho 90 người đi qua cổng.
Ai đến sau phải chờ.

Nó bảo vệ hệ thống khỏi việc gọi quá nhanh.

---

27.8. Rate limit nên đặt thấp hơn giới hạn thật

Nếu provider cho 100 requests/phút, đừng nhất thiết dùng đúng 100.

Có thể đặt:

90 requests/phút

hoặc:

80 requests/phút

để có vùng an toàn.

Vì trong thực tế:

Đồng hồ giữa hệ thống và provider có thể lệch.
Nhiều worker cùng gọi.
Retry có thể chen vào.
Provider tính window khác ta.
Request từ admin/manual tool cũng dùng cùng quota.

Đừng chạy sát mép nếu không cần.

Vùng an toàn giúp hệ thống bớt chạm 429.

---

27.9. Rate limit theo user, tenant, hay toàn hệ thống?

Có nhiều tầng rate limit.

Theo toàn hệ thống

Ví dụ:

Gemini API: tối đa 100 request/phút cho toàn app.

Theo tenant/trường/lớp

Ví dụ:

Mỗi trường tối đa 20 bài chấm/phút.

Theo user

Ví dụ:

Mỗi học viên tối đa 5 lần chấm/phút.

Theo endpoint

Ví dụ:

POST /submissions: 30 request/phút/user.

Theo loại job

Ví dụ:

AI grading: 90 request/phút.
Email transactional: 500 email/phút.

Hệ thống tốt thường cần nhiều tầng.

Vì rate limit toàn hệ thống bảo vệ provider.

Rate limit theo user/tenant bảo vệ công bằng.

---

27.10. Fairness: công bằng tài nguyên

Giả sử một trường nộp 10.000 bài cùng lúc.

Nếu không có giới hạn, trường đó có thể chiếm toàn bộ AI worker và quota Gemini.

Các trường khác phải chờ rất lâu.

Cách xử lý:

Giới hạn số job pending mỗi tenant.
Giới hạn request/phút mỗi tenant.
Chia queue theo tenant lớn.
Round-robin giữa tenant.
Ưu tiên theo gói dịch vụ.

Rate limit không chỉ để chống abuse.

Nó còn để giữ công bằng.

Với SaaS nhiều khách hàng, fairness rất quan trọng.

---

27.11. Token limit trong AI

Với AI API, giới hạn không chỉ là requests/phút.

Còn có:

Tokens/phút.
Tokens/ngày.
Context length.
Cost.

Hai request đều là 1 request, nhưng token khác nhau rất nhiều.

Ví dụ:

Bài ngắn: 2.000 tokens.
Bài dài: 40.000 tokens.

Nếu chỉ limit theo request, một vài bài dài có thể ăn phần lớn quota token.

Cần theo dõi:

Input tokens.
Output tokens.
Total tokens.
Cost estimate.
Tokens/user.
Tokens/tenant.
Tokens/model.

Với AI Judge, quota theo token có thể quan trọng hơn số request.

---

27.12. Cost quota

AI API, SMS, email, payment, storage đều có chi phí.

Rate limit bảo vệ tốc độ.

Cost quota bảo vệ ngân sách.

Ví dụ:

AI grading cost tối đa $100/ngày.
Mỗi trường tối đa $10/ngày nếu chưa trả phí.
Mỗi user free tối đa 5 lượt chấm/ngày.

Nếu vượt:

Dừng nhận job mới.
Cho job vào pending chờ ngày mai.
Yêu cầu nâng cấp gói.
Báo admin.
Hạ model rẻ hơn nếu nghiệp vụ cho phép.

Không có cost guard, tăng concurrency có thể làm chi phí tăng rất nhanh.

---

27.13. Burst là gì?

Burst là tải tăng đột ngột trong thời gian ngắn.

Ví dụ:

100 học viên cùng bấm nộp bài lúc 10:00.

Provider có thể cho:

100 request/phút

Nhưng nếu 100 request bắn trong 1 giây đầu, vẫn có thể bị limit tùy cách provider tính.

Rate limiter tốt có thể làm mượt burst:

100 job đến cùng lúc
-> trải ra trong 60 giây

Queue giúp giữ việc.

Rate limiter giúp kiểm soát tốc độ đi ra.

Hai thứ đi cùng nhau.

---

27.14. Token bucket dễ hiểu

Token bucket là một kiểu rate limiter phổ biến.

Tưởng tượng có một cái xô chứa token.

Mỗi request cần lấy 1 token.

Token được thêm vào xô đều đặn.

Ví dụ:

Mỗi phút thêm 100 token.
Xô chứa tối đa 100 token.

Nếu có token, request được đi.

Nếu hết token, request phải chờ hoặc bị từ chối.

Token bucket cho phép burst nhỏ nếu xô đang đầy, nhưng vẫn giữ tốc độ trung bình.

Ví dụ:

Nếu xô có 50 token tích lũy, có thể xử lý nhanh 50 request đầu.

Sau đó phải chờ token mới.

---

27.15. Leaky bucket dễ hiểu

Leaky bucket giống một cái xô rò nước đều đều.

Request đi vào xô.

Hệ thống xử lý chảy ra với tốc độ cố định.

Nếu request vào quá nhanh, xô đầy.

Khi xô đầy, request mới bị chặn hoặc phải chờ.

Leaky bucket làm mượt lưu lượng.

Nó phù hợp khi muốn tốc độ ra đều hơn.

Không cần nhớ công thức quá nhiều.

Chỉ cần hiểu:

Token bucket cho phép burst trong giới hạn.
Leaky bucket làm tốc độ ra đều hơn.

---

27.16. Rate limiter đặt ở đâu?

Rate limiter có thể đặt ở nhiều nơi.

Ở API Gateway

Giới hạn request từ client:

Mỗi IP/user tối đa N request/phút.

Ở application

Giới hạn theo nghiệp vụ:

Mỗi user tối đa 5 lần chấm/ngày.
Mỗi tenant tối đa 100 bài đang chờ.

Ở worker

Giới hạn gọi API ngoài:

Gemini tối đa 90 request/phút.

Ở queue

Điều tiết job được lấy ra xử lý.

Ví dụ:

AI worker chỉ lấy số job phù hợp rate limit.

Không có một chỗ duy nhất.

Mỗi tầng bảo vệ một loại tài nguyên khác nhau.

---

27.17. Distributed rate limiter

Nếu chỉ có một worker, rate limit dễ.

Nếu có nhiều worker instance, khó hơn.

Ví dụ:

10 worker-ai instances.
Mỗi worker tự nghĩ mình được gọi 90 request/phút.

Tổng cộng:

900 request/phút

Vượt xa limit.

Cần rate limiter dùng chung.

Ví dụ:

Redis counter/token bucket.
Database counter nếu tải thấp.
Dedicated rate limit service.
Cloud rate limiter.

Điểm chính:

> Rate limit toàn hệ thống phải được chia sẻ giữa các worker.

Không thể để mỗi worker tự đếm riêng nếu giới hạn là global.

---

27.18. Khi bị 429 thì làm gì?

429 Too Many Requests nghĩa là bạn gọi quá nhanh hoặc vượt giới hạn.

Không nên retry ngay lập tức.

Cần:

Đọc Retry-After nếu provider trả.
Backoff.
Jitter.
Giảm tốc độ gọi.
Tạm pause queue nếu cần.
Ghi metric/alert.

Ví dụ:

Gemini trả 429 Retry-After: 30

Worker nên chờ ít nhất khoảng đó trước khi retry.

Nếu cứ retry ngay, bạn chỉ làm tình hình xấu hơn.

429 là tín hiệu điều tiết.

Hãy nghe nó.

---

27.19. Backoff khi bị giới hạn

Khi gặp rate limit, backoff nên mạnh hơn lỗi thường.

Ví dụ:

429 lần 1: retry sau 30s
429 lần 2: retry sau 2 phút
429 lần 3: retry sau 5 phút

Có thể kết hợp:

Tạm giảm concurrency.
Tạm giảm rate limiter.
Tạm pause low priority jobs.
Ưu tiên job quan trọng.

Nếu provider báo bạn đang đi quá nhanh, đừng chỉ retry cùng tốc độ.

Hệ thống phải biết chậm lại.

---

27.20. Quota gần hết thì làm gì?

Nếu quota ngày gần hết, không nên đợi đến lúc lỗi hàng loạt.

Có thể:

Cảnh báo admin.
Giảm tốc độ nhận job mới.
Ưu tiên job quan trọng.
Từ chối job low priority.
Chuyển sang model rẻ hơn nếu được.
Báo user "hệ thống đang quá tải" hoặc "đã hết lượt".
Mua thêm quota nếu quy trình cho phép.

Ví dụ free user:

Bạn đã dùng hết 5 lượt chấm hôm nay.

Ví dụ tenant:

Trường của bạn đã dùng 90% quota tháng.

Quota nên được nhìn thấy trước khi nó thành sự cố.

---

27.21. Rate limit nội bộ

Không chỉ API bên ngoài mới cần rate limit.

Internal service cũng cần.

Ví dụ:

Notification service gọi User service để lấy profile.

Nếu Notification bug và gọi quá nhiều, User service có thể sập.

Rate limit nội bộ giúp:

Bảo vệ service.
Chống bug lan rộng.
Giữ công bằng giữa caller.
Dễ degrade hơn.

Trong microservices, đừng mặc định rằng internal traffic luôn đáng tin.

Bug bên trong còn nguy hiểm hơn user bên ngoài vì nó có thể gọi rất nhanh.

---

27.22. Rate limit ở frontend có đủ không?

Không.

Frontend có thể giúp giảm request, nhưng không thể là lớp bảo vệ chính.

Vì:

User có thể sửa client.
Bot có thể gọi API trực tiếp.
Bug frontend có thể phát tán.
Nhiều tab/device cùng gọi.

Rate limit phải nằm ở server.

Frontend có thể:

Disable button sau khi click.
Debounce input.
Hiển thị cooldown.
Không polling quá dày.

Nhưng server vẫn phải kiểm soát thật.

---

27.23. Rate limit và UX

Khi user bị giới hạn, thông báo phải rõ.

Không nên chỉ trả lỗi mơ hồ:

Something went wrong.

Tốt hơn:

Bạn đã gửi quá nhiều yêu cầu. Vui lòng thử lại sau 30 giây.

Hoặc:

Bạn đã dùng hết lượt chấm hôm nay.

API có thể trả:

429 Too Many Requests
Retry-After: 30

Frontend dùng thông tin này để hiển thị.

Rate limit tốt không chỉ bảo vệ hệ thống.

Nó cũng giúp người dùng hiểu chuyện gì đang xảy ra.

---

27.24. Rate limit và priority

Khi tài nguyên hạn chế, cần ưu tiên.

Ví dụ:

Exam grading trong giờ thi

quan trọng hơn:

Regrade thử nghiệm của user free

Khi gần quota hoặc queue quá tải:

High priority chạy trước.
Low priority chậm lại.
Job bulk tạm dừng.
Tenant trả phí cao được ưu tiên nếu chính sách cho phép.

Priority không chỉ là kỹ thuật.

Nó là quyết định sản phẩm/nghiệp vụ.

Hệ thống nên thể hiện quyết định đó rõ ràng.

---

27.25. Rate limit và queue

Queue giữ việc.

Rate limiter điều tiết tốc độ lấy việc ra hoặc tốc độ gọi API.

Ví dụ:

Queue có 10.000 AI jobs.
Rate limit Gemini = 90 request/phút.

Worker không nên lấy 10.000 job và gọi ngay.

Nó nên xử lý theo nhịp:

Tối đa 90 job bắt đầu gọi Gemini mỗi phút.

Nếu job đến nhanh hơn, queue dài.

Khi đó cần:

Hiển thị chờ.
Scale nếu có quota.
Backpressure nếu không xử lý kịp.
Ưu tiên job quan trọng.

Queue và rate limiter là cặp đôi rất hay đi cùng nhau.

---

27.26. Rate limit và polling

Polling cũng cần rate limit.

Nếu frontend polling quá dày, backend có thể bị tải lớn.

Ví dụ:

10.000 user polling mỗi 1 giây
= 10.000 request/giây

Cách giảm:

Poll mỗi 3-5 giây.
Backoff dần.
Dừng polling khi job xong.
Dùng SSE nếu phù hợp.
Cache status ngắn.
Rate limit endpoint status nếu bị abuse.

Polling đơn giản nhưng vẫn phải có kỷ luật.

---

27.27. Rate limit và WebSocket/SSE

Realtime connection cũng cần giới hạn.

Cần giới hạn:

Số connection/user.
Số subscription/user.
Số message gửi lên/giây.
Số message gửi xuống nếu client chậm.

Với WebSocket, nếu client có thể gửi message liên tục, phải rate limit phía server.

Ví dụ chat:

Một user không được gửi 1.000 message/giây.

Với SSE, cần kiểm soát số connection và tốc độ event.

Realtime không có nghĩa là không giới hạn.

---

27.28. Rate limit và cost trong AI Judge

AI Judge nên có nhiều lớp giới hạn:

Theo user

Mỗi học viên tối đa N lượt chấm/ngày.

Theo lớp/trường

Mỗi lớp tối đa M bài đang chờ.
Mỗi trường tối đa X tokens/ngày.

Theo hệ thống

Gemini tối đa 90 request/phút.
AI budget tối đa $Y/ngày.

Theo job

Mỗi bài có max input size.
Mỗi job có max output tokens.
Mỗi job retry tối đa K lần.

Nếu không có các lớp này, một lỗi hoặc một lớp quá lớn có thể dùng hết ngân sách cho toàn hệ thống.

---

27.29. Giới hạn input cũng là quota

Với AI, input quá lớn có thể rất tốn.

Cần giới hạn:

Độ dài bài nộp.
Số file.
Kích thước file.
Số lần retry/regrade.
Rubric length.
Prompt size.
Max output tokens.

Ví dụ:

Bài nộp tối đa 20.000 ký tự.
Mỗi lần chấm tối đa 8.000 output tokens.

Nếu không giới hạn input, một bài cực dài có thể:

Tốn tiền.
Chậm.
Timeout.
Làm prompt vượt context.
Làm queue xử lý lâu hơn.

Quota không chỉ là số request.

Nó còn là kích thước công việc.

---

27.30. Observability cho rate limit/quota

Cần đo:

Requests/phút.
Tokens/phút.
Tokens/ngày.
429 count.
Retry sau 429.
Cost/ngày.
Cost/user/tenant.
Queue backlog theo priority.
Rate limiter wait time.
Job bị từ chối do quota.
Quota remaining.

Nếu không đo, bạn chỉ biết khi hệ thống đã lỗi hoặc hóa đơn đã cao.

Dashboard AI Judge nên có:

Gemini requests/min
Gemini 429/min
Average tokens/job
Cost today
Cost by tenant
AI queue wait time
Jobs blocked by quota

Rate limit/quota là phần vận hành và tài chính, không chỉ kỹ thuật.

---

27.31. Khi nào tăng quota?

Tăng quota là một lựa chọn, nhưng không phải đầu tiên.

Trước khi tăng quota, hỏi:

Có job nào thừa không?
Có retry storm không?
Có prompt quá dài không?
Có user abuse không?
Có cache được không?
Có model rẻ hơn phù hợp không?
Có batching được không?
Có giới hạn input chưa?
Có queue priority chưa?

Nếu nhu cầu thật sự tăng và hệ thống đã tối ưu hợp lý, tăng quota là đúng.

Nhưng nếu tăng quota để che lỗi retry hoặc abuse, chi phí sẽ tăng mà hệ thống vẫn không khỏe.

---

27.32. Bảng chọn nhanh

| Vấn đề | Cơ chế | |---|---| | Gọi API ngoài quá nhanh | Rate limiter | | Một user spam request | Per-user rate limit | | Một tenant chiếm hết tài nguyên | Per-tenant quota/fairness | | Gần hết ngân sách AI | Cost quota, alert | | Provider trả 429 | Backoff, Retry-After, giảm tốc | | Queue backlog tăng | Scale nếu có quota, backpressure nếu không | | Retry làm tải tăng | Backoff, jitter, rate limit | | Input quá lớn | Input quota/validation | | Nhiều worker vượt global limit | Distributed rate limiter | | Polling quá dày | Poll interval/backoff/rate limit |

---

27.33. Những lỗi phổ biến

Lỗi 1: Nhầm concurrency với rate limit

Concurrency cao không có nghĩa là đang đúng RPM.

Lỗi 2: Mỗi worker tự rate limit riêng

10 worker nhân giới hạn lên 10 lần.

Lỗi 3: Không đọc Retry-After

Provider đã bảo chờ, hệ thống vẫn retry ngay.

Lỗi 4: Không có quota theo tenant/user

Một nhóm dùng hết tài nguyên của tất cả.

Lỗi 5: Không giới hạn input

Một job quá lớn ăn token/cost bất thường.

Lỗi 6: Không đo cost

Đến khi thấy hóa đơn mới biết.

Lỗi 7: Chạy sát limit thật

Dao động nhỏ là chạm 429.

Lỗi 8: Retry làm vượt limit

Tính request chính nhưng quên request retry.

---

27.34. Checklist thiết kế rate limit/quota

Khi dùng API ngoài hoặc tài nguyên giới hạn, hãy hỏi:

Provider giới hạn theo gì: request, token, tiền, ngày, phút?
Giới hạn là per app, per key, per region, hay per user?
Có bao nhiêu worker cùng gọi?
Rate limiter có global không?
Có cần vùng an toàn dưới limit thật không?
Khi nhận 429 thì xử lý thế nào?
Có đọc Retry-After không?
Retry có backoff/jitter không?
Có quota theo user/tenant không?
Có giới hạn input size không?
Có giới hạn cost/ngày không?
Có alert khi gần hết quota không?
Có dashboard request/token/cost không?
Khi quota hết, UX nói gì với user?
Job low priority có bị dừng trước không?

Trả lời được các câu này, hệ thống sẽ ít bất ngờ hơn khi tải tăng.

---

27.35. Tóm tắt bằng AI Judge

Với AI Judge:

Mỗi job mất 90 giây.
Gemini cho 100 requests/phút.

Ta cần:

Concurrency đủ cao để không lãng phí thời gian chờ.
Rate limiter để không vượt 100 RPM.
Quota để không vượt token/cost.
Retry có backoff để không tạo bão.
Limit theo user/tenant để công bằng.
Limit input để tránh job quá lớn.
Dashboard để thấy 429, token, cost.

Một thiết kế an toàn có thể là:

AI worker concurrency: tăng dần theo đo đạc
Gemini global rate limit: 80-90 RPM
Per-tenant pending jobs: giới hạn
Max submission size: giới hạn
Max retry: 2-3 lần
Cost alert: 70%, 90%, 100%

Con số cụ thể tùy hệ thống.

Nhưng nguyên tắc là:

> Đừng chỉ tăng worker. Hãy kiểm soát tốc độ, tổng mức dùng, và công bằng tài nguyên.

---

27.36. Kết luận của chương

Rate limit và quota là hàng rào bảo vệ hệ thống.

Rate limit kiểm soát tốc độ.

Quota kiểm soát tổng mức sử dụng.

Concurrency kiểm soát số việc đang chạy cùng lúc.

Ba thứ liên quan nhưng không giống nhau.

Với hệ thống gọi API ngoài, đặc biệt là AI API, phải có:

Global rate limiter.
Per-user/per-tenant limit nếu cần.
Cost quota.
Token/input limit.
Backoff khi bị 429.
Observability cho request, token, cost, retry.

Thông điệp quan trọng nhất:

> Tăng concurrency giúp xử lý nhiều việc cùng lúc, nhưng rate limit và quota quyết định ta được phép đi nhanh và đi xa đến đâu.

Ở chương tiếp theo, ta sẽ nói về theo dõi job nền: queue dài bao nhiêu là nguy hiểm, job chờ bao lâu, worker đang rảnh hay bận, và dashboard tối thiểu cần có để không vận hành trong bóng tối.