---
title: "Thiết kế hệ thống chịu tải cao - rate limiting, load shedding và circuit breaker"
description: "Trong khoá học này, bạn thiết kế hệ thống giữ được goodput, tức số request thành công trong deadline, khi tải vượt capacity, key cache hết hạn hay dependency chậm đi. Bạn đặt concurrency limit và rate limit, chọn request bị từ chối bằng load shedding, chống cache stampede, thêm bulkhead và circuit breaker."
canonical: "https://200lab.io/courses/thiet-ke-he-thong-chiu-tai-cao-rate-limiting-load-shedding-va-circuit-breaker"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-10-04T01:22:14Z"
students: 0
---

## Khoá học này mang lại gì cho bạn

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.

- **Tí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.
- **Đặ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.
- **Giớ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.
- **Chọ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.
- **Thiế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.
- **Cô 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.
- **Chẩ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.

Các tham số như limit, TTL, ngưỡng hay kích thước pool được chọn từ số liệu đo trên hệ thống của bạn, cùng với requirement của sản phẩm như dữ liệu được phép cũ bao lâu hay một job được phép chạy lâu tới đâu, nên cách chọn không gắn với một ngôn ngữ hay hạ tầng cụ thể nào.

## Khoá học cung cấp những nền tảng nào

Khi tải vượt capacity, thước đo cần theo dõi là **goodput**, tức số request thành công trong deadline mỗi giây, không phải số response mà server trả về. Có hai cách giữ goodput mà khoá học dùng đi dùng lại.

Cách thứ nhất là từ chối nhanh những request vượt mức hệ thống xử lý được, để request đã nhận vẫn xong trong deadline. Cách thứ hai là không để một chỗ chậm kéo cả hệ thống theo: cache chặn truy vấn dồn về database, còn pool riêng và circuit breaker khoanh vùng một dependency đang chậm.

Bài [The Tail at Scale](https://research.google/pubs/the-tail-at-scale/) của Jeffrey Dean và Luiz André Barroso là nền cho phần giải thích vì sao request gọi tới nhiều server dễ gặp latency cao, chương [Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) trong sách SRE của Google giải thích quá tải ở một service lan ra cả hệ thống thế nào, còn bài [Using load shedding to avoid overload](https://builder.aws.com/content/3Eun1EEyX6p2e3VYNyRLSJzLuMV/using-load-shedding-to-avoid-overload) của AWS cho thấy vì sao server quá tải vẫn bận mà goodput lại tụt.

Bốn nhóm bài dưới đây ứng với bốn kiểu quá tải mà bài mở đầu tách ra từ một đêm sale. Cuối mỗi nhóm là một bài tình huống: một nghiệp vụ cụ thể cần đến cùng lúc các cơ chế của nhóm, với số đo ở cùng một mức tải trước và sau khi sửa.

### 1. 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. 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. 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. 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.

## Vì sao 200Lab tạo ra khoá học này

Đợt tải lớn tiếp theo của hệ thống bạn đang làm có thể đến từ một buổi livestream, một push notification gửi tới toàn bộ khách hàng hay một script gọi API bằng key miễn phí, và không phải đợt nào cũng được báo trước. Instance mới, dù được thêm tự động hay bằng tay, cũng cần vài phút mới nhận được tải, trong khi một cụm service có thể sập hẳn trong chưa tới một phút.

Trong vài phút đó, hệ thống chỉ trụ được bằng những gì bạn đã thiết kế từ trước. Đó cũng là những phút có nhiều khách đặt hàng nhất, nên mỗi request trả lỗi hay trả về quá muộn là một đơn hàng bạn mất. Sáng hôm sau, bạn sẽ phải giải thích vì sao tải tăng gấp mấy lần mà số đơn thành công lại giảm, trong khi server vẫn bận suốt đêm.

Các cơ chế chống quá tải thường nhỏ hơn bạn nghĩ. Một biến đếm số request đang xử lý trong mỗi instance đã là concurrency limit, rate limiter theo từng client cần một bộ đếm trong Redis, còn circuit breaker là một đoạn code ngắn chuyển giữa ba trạng thái. Tham số của chúng được tính từ Little’s Law, bảng load test và p99 của chính service bạn, cộng với những gì sản phẩm chấp nhận được, như dữ liệu được phép cũ bao lâu.

Lần tới khi được giao chuẩn bị cho một đợt sale, bạn có thể tự lập kế hoạch thay vì đợi sự cố xảy ra rồi mới sửa. Bạn tính được mức tải hệ thống nhận nổi, và có đủ cơ sở để bảo vệ một tradeoff khó nói, như để **5%** request nhận 503 ngay cho **95%** còn lại kịp deadline. Bạn cũng tự tin nói một cơ chế là chưa cần, khi số liệu của hệ thống mình chưa cho thấy triệu chứng nào cần đến nó.

## Những vấn đề thường gặp khi thiết kế hệ thống chịu tải cao

Khi thấy p99 tăng, nhiều người phản xạ bằng cách đi tìm service chậm nhất để tối ưu, hoặc cho hệ thống nhận thêm việc bằng cách tăng timeout, tăng kích thước pool. Trong nhiều sự cố khi tải cao, chỗ hỏng lại nằm ở một hàng chờ, một pool dùng chung hay một key cache, cách xa panel đang báo đỏ.

- 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ễ deadline — khi 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ết — health 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.
- Container bị OOMKilled ba lần trong giờ cao điểm trong khi dashboard HTTP vẫn xanh — service 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.
- Đã xóa key cache ngay sau commit mà khách vẫn thấy giá deal cũ thêm **10 phút** — mộ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.
- CDN báo hit ratio tổng **97,5%** mà request cho trang HTML vẫn dồn về origin — mỗ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.
- Gateway trả 504 sau **15 giây** nhưng orchestrator vẫn gọi LLM thêm **25 giây** nữa — mỗi tầng tự đặt timeout **30 giây** và không tầng nào biết client chỉ chờ **15 giây**.
- Tỉ lệ lỗi **0,4%**, CPU **18%**, không alert nào bật mà request checkout mất gần nửa phút — **5%** 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.

Các triệu chứng trên lấy từ chính các bài trong khoá; ở mỗi bài, bạn dùng phép tính để giải thích vì sao triệu chứng xảy ra trước khi chọn cơ chế để sửa.

## Bạn sẽ học theo cách nào

- **Đọ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.
- **Hà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ị.
- **Mộ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ế đó.
- **Quiz 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.
- **Bố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.

## Khoá học dành cho ai

1. **Developer backend vận hành service** — API của bạn đang chạy trên production và p99 từng vọt lên vào giờ cao điểm; bạn cần biết nên đặt limit, pool, TTL hay timeout ở mức nào thay vì tăng dần cho tới khi hết lỗi.
2. **Người phụ trách API công khai hoặc gateway** — Đối tác, khách hàng hay script bên ngoài gọi vào API của bạn, có khi qua một gateway chuyển tiếp lên LLM provider, và bạn cần giới hạn từng client mà không chặn nhầm người dùng thật.
3. **Người chuẩn bị cho đợt sale hay mở bán** — Trước một đợt tải lớn đã lên lịch, bạn là người quyết định request nào được vào, request nào bị từ chối và chức năng nào được giảm bớt, rồi giải thích quyết định đó với cả team.

## Những điều cần lưu ý

- **Cần có kiến thức nền về tải và timeout** — Bạn cần biết trước phần ước lượng tải: Little’s Law, headroom, p99, SLO, lúc nào cần thêm cache hay queue, cách tìm bottleneck và cách lỗi lan ra qua tài nguyên dùng chung. Bạn cũng cần biết trước phần xử lý timeout: cách đọc timeline của hai request chạy song song, deadline, phân loại lỗi trước khi retry, backoff, jitter và retry budget. Riêng vài bài tình huống còn dùng lại idempotency key, lease, checkpoint và thao tác cập nhật atomic có điều kiện. Mỗi kiến thức này chỉ được nhắc lại một câu, nên từng bài dành trọn cho cơ chế mới.
- **Không gồm failover hay autoscaling** — Failover khi mất máy, backup, autoscaling và cách cấu hình nginx, Envoy hay một thư viện circuit breaker cụ thể không có trong khoá học; bạn hiểu cơ chế đủ để biết mỗi tham số của công cụ ứng với quyết định nào và nên đặt nó bằng số liệu nào.
- **Số liệu trong ví dụ do bài tự đặt** — Capacity của checkout, hạn mức token của LLM provider hay tốc độ ghi của Postgres trong các bài được chọn để các phép tính khớp nhau, không phải giới hạn thật của bất kỳ công cụ hay provider nào; khi áp dụng, bạn chạy load test để có số của riêng mình rồi đưa vào cùng phép tính.

## Bắt đầu từ đâu

Khoá học bắt đầu từ bảy phút đầu của một đêm sale: số request đổ vào tăng gấp ba, còn số request thành công trong deadline (goodput) tụt từ **2.000** xuống **700 request/giây**. Câu hỏi đầu tiên nghe có vẻ ngược: nếu chỉ nhận đúng **3.000 request/giây** mà hệ thống xử lý kịp và từ chối nhanh phần còn lại, goodput sẽ tăng hay giảm? Phép tính cho thấy goodput tăng tối đa khoảng **4,3 lần**, lên **3.000 request/giây**. Mức trần đó chỉ đạt được khi cache stampede và tình trạng dependency chậm giữ hết pool cũng được xử lý, nên bốn nhóm cơ chế phải đi cùng nhau.

## Chương trình

- Khi quá tải, hệ thống nên bỏ bớt việc thay vì sập toàn bộ (miễn phí)
- Vì sao API gọi song song nhiều service có p99 cao hơn hẳn p99 của từng service (miễn phí) · quiz
- Vì sao p99 tăng vọt khi service chạy gần hết capacity (miễn phí) · quiz
- Connection pool nên lớn bao nhiêu và request nên chờ ở app hay trong database · quiz
- Dùng rate limiting để một client không làm chậm mọi người dùng khác · quiz
- Giới hạn token cho từng đối tác trên LLM gateway · kit cho agent
- Waiting room: cho người dùng vào theo lượt khi biết trước giờ cao điểm
- Khi service quá tải, nên từ chối request nào trước và từ chối ở tầng nào · quiz
- Hàng chờ trong RAM phình to khi service nhận việc nhanh hơn tốc độ xử lý
- Thiết kế pipeline email chăm sóc khách hàng không gửi trùng, không vượt hạn mức · kit cho agent
- Đặt cache key và chọn TTL để cache có hit ratio cao mà không trả nhầm dữ liệu
- Đã xóa key cache sau khi đổi giá mà khách vẫn thấy giá cũ · quiz
- Cache stampede: một key hết hạn và hàng nghìn request cùng đổ xuống database · quiz
- Cập nhật nội dung trên CDN mà không làm origin quá tải
- Flash deal trong livestream khi không biết trước lúc nào tải tăng vọt · kit cho agent
- Chia deadline của một request cho các service mà nó đi qua · quiz
- Không để một loại request nặng chiếm hết connection của cả service · quiz
- Circuit breaker: ngừng gọi dependency đang lỗi thay vì lần nào cũng chờ timeout · quiz
- Giữ cho luồng quan trọng vẫn chạy khi một dependency bị hỏng
- Service bên ngoài chỉ thỉnh thoảng chậm mà cả API chậm theo · kit cho agent