Thiết kế hệ thống chịu tải cao - rate limiting, load shedding và circuit breaker

Hệ thống nào cũng có lúc nhận nhiều việc hơn mức nó xử lý kịp, vì tổng tải vượt capacity, vì một client gửi quá nhiều request, vì một key cache hết hạn đúng giờ cao điểm hay vì một dependency chậm đi. Nếu không có cơ chế nào chặn lại, số request thành công trong deadline giảm đúng lúc tải tăng. Bảy kỹ năng dưới đây giúp bạn giữ con số đó ổn định, kể cả khi phải từ chối bớt một phần request.

1. 01Tính p99 cho API gọi nhiều service — Với giả định các lời gọi chậm độc lập với nhau, bạn tính được bao nhiêu phần trăm request của API gặp ít nhất một lời gọi chậm, và đọc đúng p99 của service chạy nhiều instance bằng cách gộp histogram thay vì lấy trung bình p99 của từng instance.
2. 02Đặt concurrency limit và kích thước pool — Bạn tính hai giá trị này từ Little’s Law và bảng load test, để request vượt mức bị từ chối ngay, hoặc chỉ chờ connection trong service một khoảng thời gian có giới hạn, thay vì xếp hàng cho tới khi quá deadline.
3. 03Giới hạn từng client bằng rate limiting — Bạn chọn key để nhận diện client, chọn rate và burst cho token bucket, rồi đặt bộ đếm dùng chung giữa các instance. Với LLM gateway, bạn giới hạn theo số token LLM và tạm giữ trước số token tối đa của mỗi request, vì số token thật chỉ biết được khi LLM provider trả lời.
4. 04Chọn request bị từ chối khi quá tải — Khi tổng tải vượt capacity, bạn cho người dùng vào theo lượt bằng waiting room, từ chối trước nhóm request ít quan trọng bằng load shedding, và giới hạn hàng chờ trong RAM bằng backpressure.
5. 05Thiết kế cache cho giờ cao điểm — Bạn đặt cache key, chọn TTL riêng cho từng loại dữ liệu theo mức độ cũ mà sản phẩm chấp nhận được, chặn giá trị cũ quay lại cache sau khi dữ liệu đổi, chống cache stampede khi một key bị hết hạn trong lúc đang nhận hàng nghìn lượt đọc mỗi giây, và viết Cache-Control cho từng loại nội dung trên CDN.
6. 06Cô lập dependency chậm hoặc lỗi — Bạn chia deadline cho request đi qua nhiều service, tách pool riêng bằng bulkhead, chọn ngưỡng cho circuit breaker và lên sẵn các mức giảm chức năng để luồng quan trọng vẫn chạy.
7. 07Chẩn đoán p99 cao khi CPU thấp — Từ panel p99, bạn lần qua trace và metric của pool để tìm dependency đang giữ hết tài nguyên, dù tỉ lệ lỗi và CPU vẫn ở mức bình thường.

• Tải tăng từ 950 lên 1.050 request/giây, chỉ vượt capacity 5%, mà p99 tăng từ 400 ms lên khoảng 6 giây và hơn nửa số request trễ deadlineKhi utilization tiến gần 100%, thời gian chờ trong hàng tăng rất nhanh, mà service lại không có concurrency limit nên mọi request nó nhận đều chậm theo.
• Load test với tổng kích thước connection pool tăng từ 48 lên 320 cho pool_wait về 0, nhưng p99 truy vấn lại tăng và CPU Postgres tăng lên 97%Hàng chờ chỉ chuyển từ service vào trong database, nơi quá nhiều truy vấn cùng giành CPU.
• Load balancer loại lần lượt cả sáu instance catalog trong 25 giây dù chưa instance nào chếtHealth check phải xếp hàng sau request thường nên quá timeout, và mỗi instance bị loại lại dồn thêm tải cho các instance còn lại.

1. 01Đọc dashboard như kỹ sư trực— Phần đầu mỗi bài đặt bạn vào vị trí của kỹ sư trực, với một panel p99 đang đỏ, một đoạn log hay một trace từ hệ thống trong ví dụ, và câu hỏi chuyện gì đang xảy ra.
2. 02Hàng chờ và pool được vẽ ra— Nhìn ảnh hay sơ đồ gọn của mỗi bài, bạn thấy request đang xếp hàng ở đâu, pool nào bị giữ và cơ chế mới đứng ở vị trí nào trên đường đi của request. Little’s Law hay xác suất gặp lời gọi chậm được viết ra từng bước, kèm đơn vị.
3. 03Một tham số chọn bằng số liệu— Bài cơ chế nào cũng chọn một tham số như limit, TTL, ngưỡng hay kích thước pool từ số liệu và requirement của ví dụ, nói rõ tradeoff, và chỉ ra ở quy mô nào hệ thống chưa cần cơ chế đó.
4. 04Quiz yêu cầu bạn dự đoán— Phần lớn bài cơ chế có quiz ngắn, với những câu như đoán p99 sau khi đổi số lời gọi hay đoán circuit breaker chuyển sang open vào lúc nào.
5. 05Bốn demo kit chạy bằng Docker— Kit của mỗi bài tình huống là một file Markdown cho coding agent của bạn: agent dựng hệ thống ở trạng thái “trước”, chạy một mức tải cố định để triệu chứng hiện ra, rồi sau khi bạn tự sửa theo bài thì chạy lại và báo kết quả từng tiêu chí trước và sau khi sửa. Kit không chứa lời giải và không bắt buộc.

1. 01

   p99 tăng vọt và cách giới hạn số request được nhận

   API trang “Đơn hàng của tôi” gọi song song 12 service, service nào cũng có p99 dưới 80 ms, vậy mà p99 của API là 900 ms. Nếu các lời gọi chậm độc lập với nhau, xác suất cả 12 lời gọi cùng nhanh hơn p99 của từng service chỉ khoảng 89%, tức khoảng 11% request gặp ít nhất một lời gọi chậm.

   Khi API chỉ chờ những lời gọi mà trang thật sự cần, rồi gửi hedged request, tức gửi thêm một bản sao của lời gọi đọc đang chậm tới một instance khác, p99 của API giảm xuống khoảng 90 ms. Kết quả này cũng dựa trên giả định cache miss ở các instance độc lập với nhau; khi các lời gọi chậm cùng lúc vì mạng hay GC, số thật có thể khác nhiều.

   Hai bài tiếp theo giải thích vì sao p99 tăng rất nhanh khi utilization tiến gần 100%. Service tính giá đặt concurrency limit 12 request mỗi instance, tính từ Little’s Law, và goodput tăng từ khoảng 400 lên khoảng 1.000 request/giây; đổi lại, khoảng 5% request nhận 503 ngay.

   Kích thước connection pool cũng được tính bằng Little’s Law, từ số truy vấn mỗi giây và thời gian mỗi truy vấn giữ connection. Khi pool đã hết connection, request chờ ngay trong service nhưng chỉ chờ tối đa một khoảng thời gian định trước, thay vì dồn thêm truy vấn vào Postgres.

   Rate limiting xử lý một kiểu quá tải khác: tổng tải chưa vượt capacity nhưng một client chiếm phần lớn số request. Bạn so sánh token bucket với fixed window và sliding window khi một client gửi dồn nhiều request trong thời gian ngắn, rồi đặt bộ đếm trong Redis để giới hạn vẫn đúng khi service chạy nhiều instance.

   Bài tình huống đưa rate limiting vào một LLM gateway chuyển request của 40 đối tác lên một provider có hạn mức tính bằng token. Một đối tác gửi tài liệu dài, một mình dùng 80% hạn mức token của cả tài khoản, khiến 18% request của các đối tác khác nhận 429. Vì số token thật chỉ biết được khi provider trả lời, gateway tạm giữ trước số token tối đa mà request có thể dùng rồi hoàn lại phần chưa dùng.

2. 02

   Xử lý khi tổng tải vượt capacity

   Khi biết trước giờ cao điểm, như đợt mở bán 20.000 vé lúc 10:00, waiting room ở edge cho người mua vào theo lượt. Số người được vào mỗi giây tính bằng Little’s Law áp dụng cho số phiên checkout: checkout chịu được 4.500 phiên mở cùng lúc, mỗi phiên kéo dài khoảng 90 giây, nên mỗi giây chỉ cho vào 50 người. Chỉ request mang admission token còn hiệu lực mới tới được checkout.

   Khi tải tăng không báo trước, load shedding quyết định từ chối request nào và từ chối ở tầng nào. Request được xếp theo mức ưu tiên, từ checkout và giỏ hàng xuống tới prefetch và beacon; request đã quá deadline của client bị từ chối trước khi tốn CPU, còn health check luôn được trả lời. Bài phân biệt rõ hai cơ chế cùng trả 503: concurrency limit quyết định bao nhiêu request được xử lý, load shedding quyết định request nào bị từ chối.

   Backpressure dành cho một service nhận việc với tốc độ cao hơn tốc độ nó ghi xuống database, khiến hàng chờ trong RAM phình to. Bạn tính mức trần cho hàng chờ từ tốc độ nhận, tốc độ ghi và độ dài burst, ví dụ 50.000 event cho đợt burst 25 giây, rồi trả 503 kèm Retry-After khi hàng chờ đầy.

   Bài tình huống là một chiến dịch email chăm sóc khách hàng gửi cho 400.000 khách: email provider tạm khoá tài khoản 1 giờ vì tỉ lệ hard bounce vượt ngưỡng, nên cả email xác nhận đơn cũng không gửi được. Bạn chốt danh sách người nhận cho một lần chạy có run_id, kiểm tra suppression list (danh sách địa chỉ không được gửi tới) ngay trước khi gửi, giữ tốc độ gửi dưới hạn mức của provider và tách email giao dịch khỏi email chiến dịch.

3. 03

   Giữ dữ liệu trong cache đúng khi tải cao

   Tên khoá học không có chữ cache, nhưng cả nhóm này dành cho cache: một key hết hạn đúng giờ cao điểm đã đủ đẩy CPU của database lên 100%. Cache key phải chứa mọi tham số làm response khác đi và không chứa gì khác.

   Với API danh sách sản phẩm, cache key bỏ user_id nhưng thêm hạng thành viên tier, để không khách nào thấy giá thành viên của người khác, còn số món trong giỏ được đọc riêng cho từng khách ở mỗi request. Cùng với TTL chọn theo thời gian giá được phép cũ, hit ratio tăng từ 9% lên khoảng 85%, còn RAM của Redis giảm từ 13,7 GB xuống khoảng 225 MB.

   Khi giá đổi, admin API ghi một tombstone, tức một giá trị chỉ chứa version mới, thay cho lệnh xóa key. Từ đó, mỗi lần ghi cache đều so sánh version rồi mới ghi, trong cùng một thao tác atomic, nên giá cũ tới muộn bị từ chối thay vì nằm lại trong cache tới hết TTL.

   Khi một key bị hết hạn trong lúc đang nhận hàng nghìn lượt đọc mỗi giây, single-flight trong một instance và lock có thời hạn ngắn trong Redis giữa các instance giữ số truy vấn nạp lại ở mức một hoặc rất ít; lock có thể hết hạn trước khi truy vấn xong, nên đôi khi vẫn có hai truy vấn nạp lại chạy cùng lúc. Trong lúc nạp, stale-while-revalidate trả bản cũ nếu Redis còn giữ bản đó, còn khi không có bản cũ thì request phải chờ.

   Ở CDN, mỗi loại nội dung có header Cache-Control riêng: file tĩnh có hash trong tên được giữ lâu, còn trang HTML và dữ liệu JSON chỉ được giữ trong thời gian ngắn. Khi URL đổi theo version thay vì purge toàn bộ, và tham số tracking được bỏ khỏi cache key, một lần sửa nội dung chỉ đưa khoảng 50-70 request về origin, thay vì gần 6.000 request/giây suốt hai phút.

   Bài tình huống là flash deal trong livestream: không ai biết trước phút KOL hô deal, và key cache của sản phẩm vừa bị xóa vì đổi giá. Waiting room tự bật khi số người được vào mỗi giây hoặc số phiên checkout đang mở chạm ngưỡng, trong đó ngưỡng theo số người được vào mỗi giây là tín hiệu phản ứng ngay từ giây đầu tiên.

   Hai chỗ sửa còn lại nằm ở cache và ở số suất deal: cache được nạp lại mà không gây stampede, còn suất deal được trừ bằng thao tác atomic. Nhờ ba thay đổi đó, p99 checkout của người đã được vào giảm từ 11 giây xuống khoảng 450 ms, còn số suất bán vượt từ 37 về 0.

4. 04

   Khi dependency chậm hoặc lỗi

   Với deadline budget, gateway đặt tổng thời gian cho cả request, và các tầng phía sau chỉ được dùng phần thời gian còn lại chứ không đặt timeout mới dài hơn. Sau mỗi lời gọi nối tiếp, thời gian còn lại bị trừ đi; với các lời gọi chạy song song, thời gian bị trừ tính theo lời gọi lâu nhất.

   Ví dụ là một API hỏi đáp có orchestrator gọi ba service con, mỗi service con gọi LLM. Sau khi chia budget, không còn lời gọi LLM nào bắt đầu sau deadline; đổi lại, khoảng 0,5% request trước đây vừa kịp nay bị cắt sớm.

   Bulkhead tách pool riêng theo loại request hoặc theo dependency. Khi endpoint đồng bộ tồn kho của đối tác chỉ được 8 connection mỗi instance, đơn hàng của khách không còn phải chờ connection, và tradeoff là job đồng bộ chạy lâu gấp năm lần. Circuit breaker ngừng gọi một dependency đang lỗi thay vì để mỗi request chờ đủ timeout, rồi chỉ cho vài request thử đi qua để kiểm tra dependency đã hồi phục hay chưa.

   Với graceful degradation, bạn lên sẵn các mức giảm chức năng cho luồng quan trọng. Khi 30% lời gọi tới API báo giá phí vận chuyển bị lỗi, trang thanh toán chuyển xuống báo giá đã cache hoặc bảng phí cố định, và tỉ lệ thanh toán thành công giữ được khoảng 91% thay vì 61%. Tradeoff là cửa hàng chịu thêm trung bình khoảng 1.730 đồng chênh lệch phí mỗi đơn.

   Bài tình huống cuối khoá bắt đầu từ một dashboard có p99 rất cao trong khi tỉ lệ lỗi và CPU đều thấp, và nguyên nhân là service xác thực địa chỉ của bên thứ ba thỉnh thoảng chậm. Timeout được lấy từ deadline budget, service đó có pool riêng, circuit breaker mở theo tỉ lệ lời gọi chậm, còn đơn hàng được lưu kèm địa chỉ chưa xác thực để xác thực lại sau.

1. 01Dấu hiệuTải tăng từ 950 lên 1.050 request/giây, chỉ vượt capacity 5%, mà p99 tăng từ 400 ms lên khoảng 6 giây và hơn nửa số request trễ deadlineThực raKhi utilization tiến gần 100%, thời gian chờ trong hàng tăng rất nhanh, mà service lại không có concurrency limit nên mọi request nó nhận đều chậm theo.
2. 02Dấu hiệuLoad test với tổng kích thước connection pool tăng từ 48 lên 320 cho pool_wait về 0, nhưng p99 truy vấn lại tăng và CPU Postgres tăng lên 97%Thực raHàng chờ chỉ chuyển từ service vào trong database, nơi quá nhiều truy vấn cùng giành CPU.
3. 03Dấu hiệuLoad balancer loại lần lượt cả sáu instance catalog trong 25 giây dù chưa instance nào chếtThực raHealth check phải xếp hàng sau request thường nên quá timeout, và mỗi instance bị loại lại dồn thêm tải cho các instance còn lại.
4. 04Dấu hiệuContainer bị OOMKilled ba lần trong giờ cao điểm trong khi dashboard HTTP vẫn xanhThực raService trả 202 ngay khi nhận event rồi giữ event trong một hàng chờ không có giới hạn, trong khi tốc độ ghi xuống Postgres thấp hơn tốc độ nhận.
5. 05Dấu hiệuĐã xóa key cache ngay sau commit mà khách vẫn thấy giá deal cũ thêm 10 phútThực raMột request đọc giá từ Postgres trước lúc commit rồi ghi lại vào cache sau lệnh xóa, và giá cũ nằm đó tới hết TTL.
6. 06Dấu hiệuCDN báo hit ratio tổng 97,5% mà request cho trang HTML vẫn dồn về originThực raMỗi lượt bấm từ quảng cáo mang một tham số tracking fbclid riêng nằm trong cache key, nên 38% lượt mở trang HTML là cache miss.
7. 07Dấu hiệuGateway trả 504 sau 15 giây nhưng orchestrator vẫn gọi LLM thêm 25 giây nữaThực raMỗi tầng tự đặt timeout 30 giây và không tầng nào biết client chỉ chờ 15 giây.
8. 08Dấu hiệuTỉ lệ lỗi 0,4%, CPU 18%, không alert nào bật mà request checkout mất gần nửa phútThực ra5% lời gọi tới service xác thực địa chỉ mất 20 giây và chiếm gần hết pool socket dùng chung, kéo cả endpoint không gọi service đó chậm theo.