Doanh nghiệpEnterprise

Retry with Exponential Backoffaka Retry, Backoff + Jitter

Gọi lại khi gặp lỗi tạm thời, mỗi lần chờ lâu gấp đôi và thêm chút ngẫu nhiên.Re-run a call on transient failures, waiting twice as long each time plus some randomness.

Độ khóDifficulty: VừaMedium
Mức phổ biếnUsage: Mức phổ biếnUsage 5/5
Thời gian đọcReading time: ~9 phút đọc~9 min read

Thảo luậnDiscussion

Ví dụ đời thườngReal-life analogy

Bạn gọi tổng đài ngân hàng và nghe 'máy bận'. Bạn không bấm gọi lại liên tục mỗi giây — bạn đợi 1 phút, rồi 2 phút, rồi 4 phút. Nếu cả nghìn người cùng gọi lại đúng giây thứ 60 thì tổng đài vẫn nghẽn, nên mỗi người lệch nhau vài giây (jitter). Và nếu nhân viên nói 'số tài khoản sai' thì gọi lại bao nhiêu lần cũng vô ích.You call your bank's hotline and hear 'line busy'. You don't redial every second — you wait 1 minute, then 2, then 4. If a thousand people all redial at exactly second 60 the line is still jammed, so everyone shifts a few seconds (jitter). And if the agent says 'wrong account number', calling back is pointless.

Vấn đề và giải phápProblem and solution

Không có patternWithout the pattern

Gọi API Momo hay GHN thỉnh thoảng bị timeout hoặc trả 503 chỉ trong vài trăm mili-giây. Nếu fail luôn, khách mất đơn vì một lỗi mạng thoáng qua. Nhưng nếu retry ngay lập tức trong vòng lặp, cả nghìn instance cùng dội request vào một service đang hấp hối — và nếu API không idempotent, khách có thể bị trừ tiền hai lần.Calls to the Momo or GHN API occasionally time out or return 503 for a few hundred milliseconds. Failing immediately loses the order over a blip. But retrying instantly in a tight loop means thousands of instances hammer a dying service — and if the API isn't idempotent, the customer may be charged twice.

Với Retry with Exponential BackoffWith Retry with Exponential Backoff

Bọc lời gọi trong một Retry policy: chỉ retry lỗi tạm thời (timeout, 429, 5xx), giới hạn số lần, khoảng chờ tăng theo cấp số nhân (200ms → 400ms → 800ms) có trần, và cộng jitter ngẫu nhiên để các client không retry cùng lúc. Gửi kèm Idempotency-Key giống nhau ở mọi lần thử để phía server chỉ xử lý một lần. Hết lượt thì chuyển sang fallback (đánh dấu PENDING, đẩy vào hàng đợi).Wrap the call in a Retry policy: retry only transient errors (timeouts, 429, 5xx), cap the attempts, grow the wait exponentially (200ms → 400ms → 800ms) up to a ceiling, and add random jitter so clients don't retry in lockstep. Send the same Idempotency-Key on every attempt so the server processes it once. When attempts run out, fall back (mark PENDING, push to a queue).

Thành phần tham giaParticipants

Caller: Code nghiệp vụ cần gọi dịch vụ bên ngoài.Business code that needs to call a remote service.
Retry policy: Quyết định có thử lại không, tối đa mấy lần, lỗi nào được retry.Decides whether to retry, how many times, and on which errors.
Backoff strategy: Tính thời gian chờ: exponential, có trần, có jitter.Computes the wait: exponential, capped, jittered.
Remote service: API bên ngoài, nên hỗ trợ Idempotency-Key.The remote API, ideally supporting an Idempotency-Key.
Fallback / Recover: Xử lý khi đã hết lượt thử (đánh dấu PENDING, báo lỗi đẹp).Handles the case when all attempts are exhausted (mark PENDING, friendly error).

Sơ đồ và luồng thực thiDiagram and execution flow

Dùng Tự chạy hoặc phím mũi tên để đi qua từng bước gọi giữa các object. Console hiển thị output tương ứng của chương trình.Use Autoplay or the arrow keys to step through each call between objects. The console shows the matching program output.

1OrderService gọi charge() cho đơn ORD-1001. Thật ra nó đang gọi proxy do Spring Retry tạo.OrderService calls charge() for order ORD-1001. It is actually calling a proxy created by Spring Retry.

← →

console

1> charge(ORD-1001, 250000)

implementsimplementsextendsextendsgọi / dùngcalls / usestạo racreatesgửi qua channelsends via channel1thứ tự chạy (bấm để nhảy bước)execution order (click to jump)

Code: Java Spring Boot ⇄ GoCode: Java Spring Boot ⇄ Go

Cùng một bài toán, hai ngôn ngữ. Rê chuột hoặc focus vào chú thích (số màu cam) để làm nổi bật dòng code tương ứng.Same problem, two languages. Hover or focus an annotation (orange number) to highlight its line.

JavaSpring Boot 3 · Java 21Spring Boot 3 · Java 21

package com.shop.payment;

import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Recover;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Component;
import org.springframework.web.client.ResourceAccessException;
import org.springframework.web.client.RestClient;

@Component
public class MomoClient {
    private final RestClient http;

    public MomoClient(RestClient momoRestClient) {
        this.http = momoRestClient;
    }

    // Needs @EnableRetry on a @Configuration class
    @Retryable(1
        retryFor = { ResourceAccessException.class, MomoUnavailableException.class },2
        maxAttempts = 4,
        backoff = @Backoff(delay = 200, multiplier = 2, maxDelay = 2000, random = true))3
    public ChargeResult charge(ChargeRequest req) {
        return http.post()
            .uri("/v2/gateway/api/create")
            .header("Idempotency-Key", req.orderId()) // same key on every attempt4
            .body(req)
            .retrieve()
            .onStatus(status -> status.value() == 503, (rq, rs) -> {
                throw new MomoUnavailableException();
            })
            .body(ChargeResult.class);
    }

    // Runs only after the LAST attempt failed
    @Recover
    public ChargeResult markPending(RuntimeException ex, ChargeRequest req) {
        return ChargeResult.pending(req.orderId(), ex.getMessage());
    }
}

GoGo 1.23 · thư viện chuẩnGo 1.23 · standard library

package retry

import (
	"context"
	"errors"
	"fmt"
	"math/rand/v2"
	"time"
)

type Policy struct {
	MaxAttempts int
	Base        time.Duration // first delay, e.g. 200ms
	Max         time.Duration // cap, e.g. 5s
}

// Permanent wraps an error that must NOT be retried (e.g. HTTP 400).
type Permanent struct{ Err error }

func (p *Permanent) Error() string { return p.Err.Error() }
func (p *Permanent) Unwrap() error { return p.Err }

func Do(ctx context.Context, p Policy, op func(context.Context) error) error {
	var err error
	for attempt := 0; attempt < p.MaxAttempts; attempt++ {
		if err = op(ctx); err == nil {
			return nil
		}
		var perm *Permanent
		if errors.As(err, &perm) {1
			return perm.Err
		}
		if attempt == p.MaxAttempts-1 {
			break // no sleep after the last attempt
		}
		// Full jitter: random delay in [0, min(Max, Base*2^attempt)]
		ceiling := min(p.Max, p.Base<<attempt)2
		timer := time.NewTimer(rand.N(ceiling + 1))3
		select {
		case <-ctx.Done():4
			timer.Stop()
			return errors.Join(err, ctx.Err())
		case <-timer.C:
		}
	}
	return fmt.Errorf("gave up after %d attempts: %w", p.MaxAttempts, err)
}

Khác biệt chính giữa Java và GoKey differences between Java and Go

01Spring: chỉ cần một annotation @Retryable, vòng lặp nằm trong AOP proxy (nên self-invocation không retry). Go: retry là một hàm bình thường nhận closure — thấy rõ vòng lặp, không có phép thuật.Spring: one @Retryable annotation, the loop lives in an AOP proxy (so self-invocation doesn't retry). Go: retry is a plain function taking a closure — the loop is visible, no magic.
02Java phân loại lỗi theo kiểu exception (retryFor / ignoreExceptions). Go phân loại bằng giá trị lỗi: bọc Permanent rồi kiểm tra bằng errors.As / errors.Is.Java classifies failures by exception type (retryFor / ignoreExceptions). Go classifies by error values: wrap in Permanent and check with errors.As / errors.Is.
03Huỷ giữa chừng: Thread.sleep trong Java khó dừng (phải interrupt). Go dùng Timer + select trên ctx.Done() nên request bị huỷ là thoát ngay.Cancellation: Thread.sleep in Java is hard to stop (needs interrupt). Go uses Timer + select on ctx.Done(), so a cancelled request exits at once.
04Java giới hạn tổng thời gian bằng cấu hình (maxAttempts × maxDelay, hoặc TimeLimiter). Go thường dùng context.WithTimeout làm 'ngân sách' cho cả chuỗi retry.Java bounds total time via config (maxAttempts × maxDelay, or a TimeLimiter). Go usually uses context.WithTimeout as the 'budget' for the whole retry chain.

Ứng dụng thực tếReal-world usage

Spring Retry & Resilience4jSpring Retry & Resilience4j
@Retryable/@Recover của Spring Retry, hoặc @Retry(name = ...) của resilience4j-spring-boot3 cấu hình qua application.yml, thường đi chung với @CircuitBreaker.Spring Retry's @Retryable/@Recover, or resilience4j-spring-boot3's @Retry(name = ...) configured in application.yml, often combined with @CircuitBreaker.
AWS SDK & gRPCAWS SDK & gRPC
AWS SDK (Java lẫn Go) tự retry với exponential backoff + jitter; gRPC có retryPolicy trong service config. AWS Architecture Blog có bài kinh điển về 'full jitter'.The AWS SDKs (Java and Go) retry with exponential backoff + jitter out of the box; gRPC has a retryPolicy in its service config. The AWS Architecture Blog has the classic article on 'full jitter'.
Go: cenkalti/backoff, Kafka clientGo: cenkalti/backoff, Kafka clients
cenkalti/backoff là thư viện retry phổ biến nhất trong Go; Kubernetes client-go dùng wait.Backoff; các Kafka client đều có retry.backoff.ms.cenkalti/backoff is Go's most popular retry library; Kubernetes client-go uses wait.Backoff; every Kafka client exposes retry.backoff.ms.
Cổng thanh toán Momo/VNPayMomo/VNPay payment gateways
Gọi tạo giao dịch kèm orderId làm khoá idempotency, retry khi timeout; hết lượt thì đánh dấu PENDING và để job đối soát (IPN/query) xử lý tiếp.Create the transaction with the orderId as the idempotency key, retry on timeout; when attempts run out, mark PENDING and let a reconciliation job (IPN/query) take over.

Khi nào dùng và khi nào khôngWhen to use it, and when not

Nên dùng khiUse it when

Gọi qua mạng tới service khác, DB, message broker — nơi lỗi tạm thời (timeout, 503, deadlock) là chuyện bình thường.Network calls to other services, databases, brokers — where transient failures (timeouts, 503s, deadlocks) are normal.
Thao tác idempotent tự nhiên (GET, PUT, upsert) hoặc có Idempotency-Key.Operations that are naturally idempotent (GET, PUT, upsert) or carry an Idempotency-Key.
Nhiều client cùng gọi một dependency — cần jitter để tránh 'thundering herd' khi nó vừa hồi phục.Many clients hit the same dependency — jitter is needed to avoid a 'thundering herd' when it recovers.

Không nên dùng khiAvoid it when

Lỗi nghiệp vụ hoặc lỗi dữ liệu (400, 401, 404, số dư không đủ) — retry chỉ tốn thời gian.Business or validation errors (400, 401, 404, insufficient balance) — retrying only wastes time.
Thao tác không idempotent và không có khoá chống trùng (trừ tiền, gửi SMS OTP) — retry có thể làm hai lần.Non-idempotent operations without a dedup key (charging money, sending an OTP SMS) — retrying may do it twice.
Dependency đã chết hẳn — hãy để Circuit Breaker ngắt mạch thay vì retry mãi.The dependency is fully down — let a Circuit Breaker trip instead of retrying forever.

Ưu điểmPros

Tự hồi phục sau lỗi mạng thoáng qua, người dùng không hề biết.Self-heals from network blips without the user ever noticing.
Backoff + jitter giảm tải cho service đang quá tải thay vì dìm nó thêm.Backoff + jitter eases load on a struggling service instead of drowning it.
Có sẵn trong thư viện (Spring Retry, Resilience4j, cenkalti/backoff), cấu hình thay vì code tay.Built into libraries (Spring Retry, Resilience4j, cenkalti/backoff) — configure instead of hand-coding.

Nhược điểmCons

Tăng độ trễ: lỗi thật phải đợi hết các lần thử mới được báo.Adds latency: real failures surface only after all attempts.
Retry nhiều tầng (gateway → service → client) nhân số request lên theo cấp số nhân (retry storm).Retries at several layers (gateway → service → client) multiply requests exponentially (retry storm).
Nguy hiểm nếu thao tác không idempotent.Dangerous when the operation isn't idempotent.

Anti-pattern: lỗi thường gặpAnti-pattern: common mistake

Retry vòng lặp chặt, không jitter, retry mọi lỗiTight-loop retry, no jitter, retry everything

Bắt mọi Exception, ngủ cố định 1 giây và thử lại vô hạn: lỗi 400 cũng retry mãi, cả cụm server retry cùng một nhịp, và khoản trừ tiền có thể chạy hai lần vì không có Idempotency-Key.Catching every Exception, sleeping a fixed 1 second and retrying forever: a 400 is retried endlessly, the whole fleet retries in lockstep, and the charge may run twice because there's no Idempotency-Key.

public ChargeResult charge(ChargeRequest req) {
    while (true) {                       // ❌ no attempt limit
        try {
            return momo.charge(req);     // ❌ no Idempotency-Key -> double charge
        } catch (Exception e) {          // ❌ retries 400s and bugs too
            try {
                Thread.sleep(1000);      // ❌ fixed delay, no jitter
            } catch (InterruptedException ie) { /* ❌ swallowed */ }
        }
    }
}

Dễ nhầm vớiEasily confused with

Retry with Exponential Backoff vs Circuit Breaker

Retry lạc quan: 'thử lại chắc được'. Circuit Breaker bi quan: 'nó đang chết, đừng gọi nữa'. Thường dùng cả hai cùng lúc — Resilience4j mặc định cho Retry bọc ngoài CircuitBreaker, và khi mạch OPEN thì lỗi bị từ chối không nên retry.Retry is optimistic: 'try again, it'll probably work'. Circuit Breaker is pessimistic: 'it's down, stop calling'. They're often combined — Resilience4j's default order has Retry wrapping CircuitBreaker, and a rejection from an OPEN breaker shouldn't be retried.

Bài tập áp dụngExercise

Viết hàm gửi tin Zalo ZNS: retry tối đa 3 lần khi gặp 429/5xx, backoff 500ms → 1s → 2s có jitter, KHÔNG retry khi số điện thoại không hợp lệ (400), và đảm bảo khách không nhận 2 tin trùng.Write a Zalo ZNS message sender: retry at most 3 times on 429/5xx, backoff 500ms → 1s → 2s with jitter, NEVER retry on an invalid phone number (400), and make sure the customer never gets a duplicate message.

Kiểm tra kiến thứcKnowledge check

Câu 1 / 6Question 1 of 6

Vì sao cần thêm jitter vào exponential backoff?Why add jitter to exponential backoff?

Phím 1–4 để chọn đáp án, Enter để kiểm tra.Press 1–4 to choose an answer, Enter to check.

Thẻ ghi nhớFlashcards

Ôn tập ngắt quãng (spaced repetition): thẻ được lặp lại sau 1 → 3 → 7 → 14 → 30 ngày để củng cố trí nhớ dài hạn.Spaced repetition: cards are repeated after 1 → 3 → 7 → 14 → 30 days to build long-term memory.

Dùng trong bài toánUsed in problems

5 bài toán Backend dùng pattern này5 backend problems use this pattern

Pattern liên quanRelated patterns

Circuit Breaker Transactional Outbox Proxy Decorator

Thảo luậnDiscussion

Retry with Exponential Backoffaka Retry, Backoff + Jitter

Gọi lại khi gặp lỗi tạm thời, mỗi lần chờ lâu gấp đôi và thêm chút ngẫu nhiên.Re-run a call on transient failures, waiting twice as long each time plus some randomness.

VừaMedium

Mức phổ biếnUsage 5/5

~9 phút đọc~9 min read

package com.shop.payment; import org.springframework.retry.annotation.Backoff; import org.springframework.retry.annotation.Recover; import org.springframework.retry.annotation.Retryable; import org.springframework.stereotype.Component; import org.springframework.web.client.ResourceAccessException; import org.springframework.web.client.RestClient; @Component public class MomoClient { private final RestClient http; public MomoClient(RestClient momoRestClient) { this.http = momoRestClient; } // Needs @EnableRetry on a @Configuration class @Retryable(1 retryFor = { ResourceAccessException.class, MomoUnavailableException.class },2 maxAttempts = 4, backoff = @Backoff(delay = 200, multiplier = 2, maxDelay = 2000, random = true))3 public ChargeResult charge(ChargeRequest req) { return http.post() .uri("/v2/gateway/api/create") .header("Idempotency-Key", req.orderId()) // same key on every attempt4 .body(req) .retrieve() .onStatus(status -> status.value() == 503, (rq, rs) -> { throw new MomoUnavailableException(); }) .body(ChargeResult.class); } // Runs only after the LAST attempt failed @Recover public ChargeResult markPending(RuntimeException ex, ChargeRequest req) { return ChargeResult.pending(req.orderId(), ex.getMessage()); } }

package retry import ( "context" "errors" "fmt" "math/rand/v2" "time" ) type Policy struct { MaxAttempts int Base time.Duration // first delay, e.g. 200ms Max time.Duration // cap, e.g. 5s } // Permanent wraps an error that must NOT be retried (e.g. HTTP 400). type Permanent struct{ Err error } func (p *Permanent) Error() string { return p.Err.Error() } func (p *Permanent) Unwrap() error { return p.Err } func Do(ctx context.Context, p Policy, op func(context.Context) error) error { var err error for attempt := 0; attempt < p.MaxAttempts; attempt++ { if err = op(ctx); err == nil { return nil } var perm *Permanent if errors.As(err, &perm) {1 return perm.Err } if attempt == p.MaxAttempts-1 { break // no sleep after the last attempt } // Full jitter: random delay in [0, min(Max, Base*2^attempt)] ceiling := min(p.Max, p.Base<<attempt)2 timer := time.NewTimer(rand.N(ceiling + 1))3 select { case <-ctx.Done():4 timer.Stop() return errors.Join(err, ctx.Err()) case <-timer.C: } } return fmt.Errorf("gave up after %d attempts: %w", p.MaxAttempts, err) }

public ChargeResult charge(ChargeRequest req) { while (true) { // ❌ no attempt limit try { return momo.charge(req); // ❌ no Idempotency-Key -> double charge } catch (Exception e) { // ❌ retries 400s and bugs too try { Thread.sleep(1000); // ❌ fixed delay, no jitter } catch (InterruptedException ie) { /* ❌ swallowed */ } } } }