Doanh nghiệpEnterprise

Sagaaka Long-running transaction, Compensating transaction

Chia giao dịch xuyên nhiều service thành chuỗi bước cục bộ, lỗi thì chạy bước bù trừ theo chiều ngược lại.Split a cross-service transaction into local steps; on failure, run compensating steps in reverse.

Độ khóDifficulty: KhóHard
Mức phổ biếnUsage: Mức phổ biếnUsage 4/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 lên kế hoạch du lịch Đà Nẵng: đặt vé máy bay, đặt khách sạn, thuê xe máy. Không có 'nút ACID' nào đặt cả ba cùng lúc. Nếu tới bước thuê xe thì hết xe và bạn quyết định huỷ chuyến, bạn phải tự huỷ khách sạn rồi huỷ vé máy bay — theo thứ tự ngược lại, và có khi mất phí. Đó là Saga: không rollback được thì 'bù trừ'.You plan a trip to Da Nang: book flights, book a hotel, rent a motorbike. There's no 'ACID button' that books all three at once. If the motorbikes are sold out and you cancel the trip, you must cancel the hotel and then the flights yourself — in reverse order, maybe paying a fee. That's a Saga: when you can't roll back, you compensate.

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

Không có patternWithout the pattern

Đặt hàng trên sàn TMĐT chạm tới 4 service, mỗi service một database: Order, Payment, Inventory, Shipping. Không thể bọc tất cả trong một @Transactional; 2PC/XA thì chậm, khoá tài nguyên lâu và nhiều hệ thống (Kafka, API Momo) không hỗ trợ. Nếu đã trừ tiền khách mà kho báo hết hàng, ai sẽ hoàn tiền? Không xử lý thì dữ liệu lệch và khách mất tiền oan.Placing an order touches 4 services, each with its own database: Order, Payment, Inventory, Shipping. You can't wrap them in one @Transactional; 2PC/XA is slow, holds locks for long and many systems (Kafka, the Momo API) don't support it. If the customer is charged but inventory reports out of stock, who refunds? Unhandled, the data diverges and the customer loses money.

Với SagaWith Saga

Mô hình hoá thành chuỗi bước, mỗi bước là một transaction cục bộ trong một service, kèm một hành động bù trừ (compensating action) — 'undo' theo nghĩa nghiệp vụ: hoàn tiền, nhả kho, huỷ đơn. Nếu bước k thất bại, chạy bù trừ cho các bước k-1…1 theo thứ tự ngược. Hai cách điều phối: Orchestration (một orchestrator trung tâm ra lệnh từng bước và nhớ trạng thái) hoặc Choreography (mỗi service nghe event của service khác và tự phản ứng, không ai chỉ huy).Model it as a chain of steps, each a local transaction in one service, paired with a compensating action — a business-level 'undo': refund, release stock, cancel order. If step k fails, run the compensations for steps k-1…1 in reverse. Two ways to coordinate: Orchestration (a central orchestrator commands each step and tracks state) or Choreography (each service listens to the others' events and reacts on its own, nobody in charge).

Thành phần tham giaParticipants

Saga orchestrator: (Orchestration) Gọi từng bước theo thứ tự, ghi nhận tiến trình, kích hoạt bù trừ.(Orchestration) Calls each step in order, records progress, triggers compensation.
Step / local transaction: Một thao tác ACID trong một service (trừ tiền, giữ kho).One ACID operation inside one service (charge, reserve stock).
Compensating action: Undo theo nghiệp vụ, phải idempotent và cuối cùng phải thành công.A business-level undo; must be idempotent and must eventually succeed.
Saga log / state: Lưu bước nào đã xong để khôi phục sau crash.Stores which steps completed so it can recover after a crash.
Events (choreography): OrderCreated, PaymentCompleted, StockReservationFailed... mỗi service nghe và phản ứng.OrderCreated, PaymentCompleted, StockReservationFailed... each service listens and reacts.

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.

1Checkout khởi động saga cho đơn ORD-1001 (450.000đ). Orchestrator ghi log 'STARTED'.Checkout starts a saga for order ORD-1001 (450,000 VND). The orchestrator logs 'STARTED'.

← →

console

1saga ORD-1001 started

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.saga;

import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;

public interface SagaStep {1
    String name();
    void execute(OrderSagaData data);    // a local transaction in one service
    void compensate(OrderSagaData data); // semantic undo, must be idempotent
}

@Component
@Order(2)2
class ChargePaymentStep implements SagaStep {
    private final PaymentClient payments;

    ChargePaymentStep(PaymentClient payments) { this.payments = payments; }

    public String name() { return "CHARGE_PAYMENT"; }

    public void execute(OrderSagaData d) {
        d.setPaymentId(payments.charge(d.getOrderId(), d.getCustomerId(), d.getTotal()));
    }

    public void compensate(OrderSagaData d) {
        if (d.getPaymentId() != null) {3
            payments.refund(d.getPaymentId(), "saga rollback " + d.getOrderId());
        }
    }
}

@Component
@Order(3)
class ReserveStockStep implements SagaStep {
    private final InventoryClient inventory;

    ReserveStockStep(InventoryClient inventory) { this.inventory = inventory; }

    public String name() { return "RESERVE_STOCK"; }

    public void execute(OrderSagaData d) { inventory.reserve(d.getOrderId(), d.getLines()); }

    public void compensate(OrderSagaData d) { inventory.release(d.getOrderId()); }4
}

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

package saga

import (
	"context"
	"errors"
	"fmt"
	"log/slog"
)

type OrderState struct {
	OrderID, CustomerID   string
	Total                 int64
	PaymentID, ShipmentID string
}

// Step = a local transaction in one service + its semantic undo.
type Step struct {1
	Name string
	Do   func(ctx context.Context, s *OrderState) error
	Undo func(ctx context.Context, s *OrderState) error // nil: nothing to undo
}

// Journal persists progress so a crashed saga can be resumed or compensated.
type Journal interface {
	Record(ctx context.Context, orderID, step, status string)
}

type Orchestrator struct {
	Steps   []Step
	Journal Journal
}

func (o *Orchestrator) Run(ctx context.Context, st *OrderState) error {
	for i, step := range o.Steps {
		o.Journal.Record(ctx, st.OrderID, step.Name, "STARTED")
		if err := step.Do(ctx, st); err != nil {
			o.Journal.Record(ctx, st.OrderID, step.Name, "FAILED")
			cerr := o.compensate(context.WithoutCancel(ctx), st, o.Steps[:i])2
			return errors.Join(fmt.Errorf("saga failed at %s: %w", step.Name, err), cerr)
		}
		o.Journal.Record(ctx, st.OrderID, step.Name, "DONE")
	}
	return nil
}

func (o *Orchestrator) compensate(ctx context.Context, st *OrderState, done []Step) error {
	var errs []error
	for i := len(done) - 1; i >= 0; i-- { // reverse order3
		if done[i].Undo == nil {
			continue
		}
		if err := done[i].Undo(ctx, st); err != nil {
			slog.Error("compensation failed, retry later", "order", st.OrderID, "step", done[i].Name, "err", err)
			errs = append(errs, err)
			continue
		}
		o.Journal.Record(ctx, st.OrderID, done[i].Name, "COMPENSATED")
	}
	return errors.Join(errs...)
}

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

01Java mô hình mỗi bước là một class implement SagaStep và để Spring sắp thứ tự bằng @Order. Go mô hình bước là struct chứa hai closure Do/Undo, thứ tự chính là thứ tự trong slice.Java models each step as a class implementing SagaStep, ordered by Spring via @Order. Go models a step as a struct with two closures Do/Undo; the order is simply the slice order.
02Lỗi: Java dùng try/catch quanh từng bước. Go kiểm tra error trả về và gom nhiều lỗi bù trừ bằng errors.Join.Errors: Java wraps each step in try/catch. Go checks returned errors and aggregates compensation failures with errors.Join.
03Huỷ request: Go có context.WithoutCancel để bù trừ vẫn chạy khi ctx gốc bị huỷ. Java phải tự đảm bảo (chạy bù trừ trên thread/executor riêng, không phụ thuộc request).Request cancellation: Go has context.WithoutCancel so compensation still runs after the parent ctx is cancelled. Java must ensure this itself (run compensation on its own thread/executor, independent of the request).
04Choreography trong Spring dùng @KafkaListener + Outbox gần như 'khai báo'. Trong Go là các consumer goroutine đọc Kafka và switch theo loại event — tường minh hơn nhưng dài hơn.Choreography in Spring is almost declarative with @KafkaListener + Outbox. In Go it's consumer goroutines reading Kafka and switching on event type — more explicit, more code.

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

Temporal / CadenceTemporal / Cadence
Engine workflow bền vững (SDK cho cả Java và Go): viết saga như code tuần tự, Temporal tự lưu trạng thái, retry và chạy bù trừ sau crash.Durable workflow engines (SDKs for both Java and Go): write the saga as sequential code, Temporal persists state, retries and runs compensations after crashes.
Axon, Eventuate Tram, CamundaAxon, Eventuate Tram, Camunda
Axon có @Saga với @SagaEventHandler; Eventuate Tram Sagas (của Chris Richardson) cho Spring; Camunda/Zeebe mô hình saga bằng BPMN.Axon has @Saga with @SagaEventHandler; Eventuate Tram Sagas (by Chris Richardson) for Spring; Camunda/Zeebe model sagas in BPMN.
AWS Step FunctionsAWS Step Functions
State machine có Catch để chuyển sang các state bù trừ — saga orchestration dạng dịch vụ quản lý.State machines with Catch to jump into compensation states — managed saga orchestration.
Đặt vé / đặt phòng / ví điện tửTicketing / hotel booking / e-wallets
Đặt combo vé máy bay + khách sạn, chuyển tiền liên ngân hàng (giữ tiền → chuyển → hoàn nếu lỗi) đều là saga.Booking flight + hotel combos, interbank transfers (hold → transfer → refund on failure) are all sagas.

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

Nên dùng khiUse it when

Một nghiệp vụ trải qua nhiều service/database và cần nhất quán cuối cùng.A business operation spans several services/databases and needs eventual consistency.
Mỗi bước có hành động bù trừ có nghĩa nghiệp vụ (hoàn tiền, nhả kho, huỷ vé).Every step has a meaningful business compensation (refund, release stock, cancel ticket).
Không thể hoặc không muốn dùng 2PC vì hiệu năng và khả năng sẵn sàng.2PC is impossible or undesirable for performance and availability reasons.

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

Mọi dữ liệu nằm trong một database — dùng một transaction cục bộ là xong.All data lives in one database — a single local transaction does the job.
Nghiệp vụ không chấp nhận trạng thái trung gian bị nhìn thấy (cần cô lập tuyệt đối).The business can't tolerate visible intermediate states (needs full isolation).
Có bước không thể bù trừ (gửi email, xuất hoá đơn điện tử) mà lại không đặt nó ở cuối chuỗi.Some step can't be compensated (sending an email, issuing an e-invoice) and you can't move it to the end.

Ưu điểmPros

Nhất quán dữ liệu xuyên service mà không cần khoá phân tán.Cross-service consistency without distributed locks.
Mỗi service giữ database riêng, độc lập triển khai và scale.Each service keeps its own database, deployed and scaled independently.
Orchestration cho luồng rõ ràng, dễ theo dõi; choreography cho coupling thấp.Orchestration gives a clear, observable flow; choreography gives low coupling.

Nhược điểmCons

Thiếu Isolation: người khác thấy trạng thái trung gian; cần semantic lock (PENDING) và xử lý đọc bẩn.No Isolation: others see intermediate states; you need semantic locks (PENDING) and dirty-read handling.
Viết và test bù trừ cho mọi bước tốn công; bù trừ lỗi cần retry + can thiệp tay.Writing and testing compensations for every step is costly; failing compensations need retries + manual intervention.
Choreography nhiều bước rất khó theo dõi ('event spaghetti'); orchestration tạo một điểm tập trung logic.Long choreographies are hard to follow ('event spaghetti'); orchestration centralises logic in one place.

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

Saga không có bù trừ, hoặc bù trừ sai thứ tựA saga without compensation, or compensating in the wrong order

Gọi lần lượt các service trong một method @Transactional rồi tin rằng exception sẽ 'rollback hết'. Thực tế @Transactional chỉ rollback DB cục bộ — tiền ở Payment Service đã trừ, kho đã giữ, không ai hoàn lại. Mỗi bước cần một compensate rõ ràng, chạy theo thứ tự ngược.Calling the services one by one inside a @Transactional method and trusting an exception to 'roll everything back'. In reality @Transactional only rolls back the local DB — the money in Payment Service is gone, the stock is held, nobody undoes it. Every step needs an explicit compensation, run in reverse.

@Transactional // ❌ only covers THIS service's database
public void checkout(OrderRequest req) {
    Order order = orders.save(Order.pending(req));
    String paymentId = paymentClient.charge(order.id(), req.total()); // remote call, committed
    inventoryClient.reserve(order.id(), req.lines());                 // throws: out of stock
    shippingClient.create(order.id());
    // ❌ the exception rolls back the orders table only — the customer stays charged
}

Dễ nhầm vớiEasily confused with

Saga vs Unit of Work

Unit of Work gom thay đổi vào MỘT transaction ACID trong một database. Saga điều phối NHIỀU transaction ở nhiều service, dùng bù trừ thay cho rollback.Unit of Work batches changes into ONE ACID transaction in one database. A Saga coordinates MANY transactions across services, using compensation instead of rollback.

Saga vs Mediator

Orchestrator trông giống Mediator (trung tâm điều phối), nhưng Saga thêm trạng thái bền vững và bù trừ cho giao dịch phân tán.An orchestrator looks like a Mediator (central coordinator), but a Saga adds durable state and compensation for distributed transactions.

Bài tập áp dụngExercise

Thêm bước APPLY_VOUCHER (trừ lượt dùng voucher) giữa CREATE_ORDER và CHARGE_PAYMENT, kèm bù trừ. Sau đó trả lời: nếu RESERVE_STOCK lỗi, các bù trừ chạy theo thứ tự nào?Add an APPLY_VOUCHER step (consume a voucher use) between CREATE_ORDER and CHARGE_PAYMENT, with compensation. Then answer: if RESERVE_STOCK fails, in which order do compensations run?

Kiểm tra kiến thứcKnowledge check

Câu 1 / 6Question 1 of 6

Compensating action khác rollback ở điểm nào?How does a compensating action differ from a rollback?

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

4 bài toán Backend dùng pattern này4 backend problems use this pattern

Pattern liên quanRelated patterns

Transactional Outbox Command Mediator Event Sourcing

Thảo luậnDiscussion

Sagaaka Long-running transaction, Compensating transaction

KhóHard

Mức phổ biếnUsage 4/5

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

package com.shop.saga; import org.springframework.core.annotation.Order; import org.springframework.stereotype.Component; public interface SagaStep {1 String name(); void execute(OrderSagaData data); // a local transaction in one service void compensate(OrderSagaData data); // semantic undo, must be idempotent } @Component @Order(2)2 class ChargePaymentStep implements SagaStep { private final PaymentClient payments; ChargePaymentStep(PaymentClient payments) { this.payments = payments; } public String name() { return "CHARGE_PAYMENT"; } public void execute(OrderSagaData d) { d.setPaymentId(payments.charge(d.getOrderId(), d.getCustomerId(), d.getTotal())); } public void compensate(OrderSagaData d) { if (d.getPaymentId() != null) {3 payments.refund(d.getPaymentId(), "saga rollback " + d.getOrderId()); } } } @Component @Order(3) class ReserveStockStep implements SagaStep { private final InventoryClient inventory; ReserveStockStep(InventoryClient inventory) { this.inventory = inventory; } public String name() { return "RESERVE_STOCK"; } public void execute(OrderSagaData d) { inventory.reserve(d.getOrderId(), d.getLines()); } public void compensate(OrderSagaData d) { inventory.release(d.getOrderId()); }4 }

package saga import ( "context" "errors" "fmt" "log/slog" ) type OrderState struct { OrderID, CustomerID string Total int64 PaymentID, ShipmentID string } // Step = a local transaction in one service + its semantic undo. type Step struct {1 Name string Do func(ctx context.Context, s *OrderState) error Undo func(ctx context.Context, s *OrderState) error // nil: nothing to undo } // Journal persists progress so a crashed saga can be resumed or compensated. type Journal interface { Record(ctx context.Context, orderID, step, status string) } type Orchestrator struct { Steps []Step Journal Journal } func (o *Orchestrator) Run(ctx context.Context, st *OrderState) error { for i, step := range o.Steps { o.Journal.Record(ctx, st.OrderID, step.Name, "STARTED") if err := step.Do(ctx, st); err != nil { o.Journal.Record(ctx, st.OrderID, step.Name, "FAILED") cerr := o.compensate(context.WithoutCancel(ctx), st, o.Steps[:i])2 return errors.Join(fmt.Errorf("saga failed at %s: %w", step.Name, err), cerr) } o.Journal.Record(ctx, st.OrderID, step.Name, "DONE") } return nil } func (o *Orchestrator) compensate(ctx context.Context, st *OrderState, done []Step) error { var errs []error for i := len(done) - 1; i >= 0; i-- { // reverse order3 if done[i].Undo == nil { continue } if err := done[i].Undo(ctx, st); err != nil { slog.Error("compensation failed, retry later", "order", st.OrderID, "step", done[i].Name, "err", err) errs = append(errs, err) continue } o.Journal.Record(ctx, st.OrderID, done[i].Name, "COMPENSATED") } return errors.Join(errs...) }

@Transactional // ❌ only covers THIS service's database public void checkout(OrderRequest req) { Order order = orders.save(Order.pending(req)); String paymentId = paymentClient.charge(order.id(), req.total()); // remote call, committed inventoryClient.reserve(order.id(), req.lines()); // throws: out of stock shippingClient.create(order.id()); // ❌ the exception rolls back the orders table only — the customer stays charged }