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.
Retry ở bài trước chỉ an toàn khi thao tác lũy đẳng. Idempotency key là cách biến thao tác có side effect thành lũy đẳng: client sinh khóa duy nhất, server dedup. Đo thật trong Go: không idempotency retry 5 lần tạo 5 đơn; có thì chỉ 1, kể cả 100 goroutine đồng thờ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.
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.
Viết vòng lặp retry bằng tay ở từng chỗ gọi là lặp code và dễ sai. gRPC có retry policy khai bằng cấu hình. Bài này chạy thật: server fail 2 lần đầu với Unavailable rồi OK — client cấu hình retry tự thử lại và nhận thành công sau đúng 3 lần gọi server (đo bằng counter thật), với backoff tăng dần. Nhưng lỗi InvalidArgument thì không retry: server chỉ bị gọi 1 lần, vì gọi lại input sai vẫn sai.
Spring AMQP cho bật retry bằng vài dòng cấu hình. Phép đo cho thấy nó chặn luồng consumer, và toàn bộ thời gian thêm vào là thời gian ngồi chờ.