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.
Lúc sự cố xảy ra, bạn không đọc log — bạn truy vấn nó. Và log chuỗi tự do (fmt.Printf) không truy vấn được: mỗi dòng một định dạng, muốn lọc phải viết regex. Bài này đo thật với log/slog của Go 1.23: cùng một sự kiện in ra chuỗi tự do và JSON có cấu trúc, rồi dùng jq lọc 1000 dòng log theo nhiều field (đếm ERROR theo service, tính latency trung bình). Kèm số đo chi phí thật — và một sự thật ngược đời: log chuỗi nhanh hơn slog gần 1.7 lần.