Circuit breaker theo dõi lỗi và tự ngắt lời gọi tới service đang hỏng để không dồn tải. Đo thật trong Go 1.23: ba trạng thái Closed/Open/HalfOpen chuyển đúng, và khi breaker mở nó chặn nhanh trong 107 nano giây thay vì chờ 55ms timeout của service chết.
Retry lỗi tạm thời cần backoff tăng dần và jitter ngẫu nhiên để không dồn tải service vừa hồi. Đo thật trong Go 1.23: backoff nhân đôi 100ms tới trần 2s, jitter rải 10 client khắp 64-648ms thay vì cùng bật dậy một lúc, và vòng retry thành công sau 2 lỗi.
Traffic dồn dập làm quá tải hệ hoặc bị lạm dụng — rate limiting chặn phần vượt ngưỡng. Bài này chạy thật trong Go: token bucket giới hạn 100/s cho cụm 100 request đầu qua ngay (burst) rồi giữ đúng 100 req/s bền vững; đo được 1000 request tức thì chỉ 100 qua, và 3 giây liên tục cho qua chính xác 100 req/s. Giải thích token bucket vs leaky bucket và khi nào dùng cái nào.
Một service phụ thuộc lỗi liên tục mà ta cứ gọi = chờ timeout mãi, tốn tài nguyên, kéo sập cả caller (cascading failure). Circuit breaker ngắt mạch: sau vài lỗi, nó chặn ngay mọi call, trả lỗi nhanh thay vì chờ. Bài này chạy thật trong Go: 20 call tới service chết chỉ 5 chạm thật, 15 bị chặn ~0ms, tổng 1,02s thay vì 4000ms; rồi tự hồi phục qua half-open khi service sống lại.
Thử lại khi lỗi thoáng qua là đúng — nhưng retry ngay và đều của nhiều client cùng lúc tạo 'bão retry' đánh sập service đang gượng dậy. Bài này chạy thật trong Go: retry với exponential backoff (100/200/400ms), và đo sức mạnh của jitter — 50 client cùng lỗi, không jitter thì cả 50 dội cùng một cửa sổ 20ms, có jitter thì đỉnh chỉ còn 5, cắt tải retry ~10 lần.
Không đặt hạn thì một thao tác treo giữ luồng mãi, tài nguyên cạn dần. Bài này chạy thật trong Go: context timeout 200ms khiến thao tác 2 giây trả về sau 209ms với DeadlineExceeded; và đo cái bẫy quan trọng — 100 goroutine không nghe ctx.Done() vẫn rò rỉ dù đã cancel, còn 100 goroutine có nghe thì thoát sạch. Timeout chỉ có tác dụng nếu hàm thực sự tôn trọng context.