Tạo một goroutine cho mỗi task nghe tiện, nhưng với hàng triệu task nó bùng nổ thành hàng triệu goroutine tốn RAM và đè downstream. Bài này chạy thật trong Go: worker pool giữ đúng 11 goroutine cho 200.000 task (so với 200.001), và đo throughput theo số worker — với CPU-bound, throughput bão hòa quanh số core (10), thêm worker không nhanh hơn. Giải thích cách chọn N cho CPU-bound vs I/O-bound.
Cache là lá chắn cho database, nhưng đúng khoảnh khắc một key nóng hết hạn, hàng nghìn request cùng miss và cùng lao xuống nguồn — đó là cache stampede, thứ có thể quật sập DB ngay cả khi mọi thứ 'đang chạy tốt'. Bài này đo thật trong Go: 1000 goroutine cùng miss 1 key gọi nguồn 1000 lần; thêm singleflight, con số về đúng 1; và một cache LRU với truy cập lệch đạt hit rate 32.2%.
Retry là lá chắn chống lỗi tạm thời, nhưng nó có một mặt tối: nếu request đầu tiên đã thành công mà phản hồi bị mất, lần retry sẽ chạy lại side-effect — khách bị trừ tiền hai lần. Bài này đo thật trong Go: một handler thanh toán không có idempotency bị retry 5 lần trừ tiền 5 lần (số dư 1000 → 500); thêm idempotency key, con số về đúng 1 lần; và 1000 goroutine gửi cùng key đồng thời vẫn chỉ trừ đúng 1 lần, kiểm bằng go run -race.
Con tàu Titanic chìm vì nước tràn từ khoang này sang khoang khác. Hệ thống của bạn cũng vậy: khi một phụ thuộc chậm (một API bên thứ ba treo), nó chiếm hết luồng dùng chung và làm chết đói cả những request nhanh chẳng liên quan. Bài này đo thật trong Go: pool dùng chung khiến request nhanh A chỉ 11/200 thành công (latency 46ms) khi request chậm B treo; tách pool riêng (bulkhead), A trở lại 200/200 với latency 2.6ms.
Amazon từng nói: thà hiển thị gợi ý sản phẩm cũ hơn là để trang trắng. Đó là graceful degradation — khi một phụ thuộc chết hẳn, trả một phản hồi suy giảm nhưng vẫn có ích thay vì lỗi 500. Bài này đo thật trong Go: một handler phụ thuộc cứng chỉ đạt 25% thành công khi downstream chết; thêm fallback bằng stale cache, tỉ lệ thành công lên 100% (150/200 request được phục vụ bằng dữ liệu cũ đánh dấu rõ).
Loạt bài này đi qua 11 mẫu chịu tải, mỗi mẫu giải một vấn đề riêng. Bài tổng kết trả lời câu hỏi thực tế: gặp tình huống X thì dùng mẫu nào, và ghép chúng theo thứ tự nào? Kèm demo thật trong Go ghép bulkhead + circuit breaker + timeout + fallback: cùng một downstream ốm yếu, pipeline nâng tỉ lệ thành công người dùng từ 48% lên 100%, giảm tải xuống downstream từ 500 còn 73 lần gọi, và cắt latency từ 93.9ms xuống 13.3ms.