Retries và Backoff: Phục hồi mà Không Khuếch đại Sự cố

Tóm tắt

Chỉ retry khi attempt mới có khả năng giúp và việc lặp là an toàn. Retry cũng tăng tải lên dependency có thể đang lỗi.

Phân loại trước khi retry

Làm write an toàn trước

Nếu attempt đầu có thể đã commit, request mới có thể tạo effect trùng. Dùng lại idempotency identity hoặc đối soát state trước. Retry không tự tạo idempotency.

Backoff, jitter và giữ trong deadline

100 ms -> 200 ms -> 400 ms -> capped delay

Exponential backoff giãn attempt; jitter ngẫu nhiên hóa wait để fleet không thức cùng lúc. Cap attempt/delay và không sleep quá deadline còn lại.

Chọn một retry owner

Nếu Client, Service A và Service B đều cho ba total attempt, một request gốc có thể tạo 3 × 3 × 3 = 27 attempt. Chọn một retry owner có đủ context; tính cả SDK retry.

Bảo vệ cả fleet

Khi failure lan rộng, retry budget hoặc token bucket có thể giảm retry. Quan sát request gốc tách khỏi số attempt, cùng lý do retry, cạn budget và saturation.

Kịch bản production

Gateway gọi Checkout → Inventory → database. Khi latency tăng, mọi layer retry hai lần, dùng deterministic backoff và write thiếu stable idempotency identity.

Hậu quả: một user request có thể tạo tới 27 database attempt; retry đồng bộ tạo burst, saturation nặng hơn và ambiguous write có thể tạo reservation trùng.

Nguyên nhân cốt lõi: retry ownership bị rải ở nhiều layer, failure không được phân loại, write không an toàn khi lặp và timing làm cả fleet đồng bộ.

Cách khắc phục chuẩn: chọn một retry owner, chỉ retry transient failure, giữ logical request identity, bound attempt trong deadline còn lại, dùng exponential backoff có jitter, tôn trọng Retry-After và dừng khi retry budget cạn. Tách original request khỏi attempt.

Tự kiểm tra

SDK và service wrapper của bạn đều đã retry. Dependency bắt đầu trả 503. Có nên thêm retry loop ở gateway không?

Checklist vận hành retry

• Chỉ retry failure tạm thời, không retry lỗi deterministic.
• Làm ambiguous write idempotent hoặc đối soát trước.
• Giữ mọi retry trong deadline còn lại.
• Chọn một retry owner và tính cả SDK retry.
• Cap backoff, thêm jitter, tôn trọng Retry-After.
• Giới hạn retry toàn fleet và tách request gốc khỏi attempt trong observability.

Agent rule

Trước khi thêm retry, hãy tìm failure class, safety, deadline, retry hiện có, ownership, bounds, backoff/jitter, server hint, fleet budget và telemetry.

Nguồn

Nguồn chính kiểm tra ngày 2026-09-15: RFC 9110, AWS retry guidance, AWS SDK retry behavior.