SAGA Pattern: Quản lý Distributed Transactions trong Microservices

Microservices nghe thì sang, nhưng khi đụng vào vấn đề Transaction, nó trở thành cơn ác mộng.

Hãy xem ví dụ kinh điển: Đặt hàng E-commerce.

1. Service Order: Tạo đơn hàng Pending.
2. Service Inventory: Trừ kho.
3. Service Payment: Trừ tiền thẻ tín dụng.
4. Service Order: Cập nhật đơn hàng Confirmed.

Trong Monolith, ta gói cả 4 bước vào DB::transaction(...). Nếu bước 3 lỗi? Rollback cái rụp. Xong.

Trong Microservices, 3 ông Order, Inventory, Payment dùng 3 database khác nhau. Không thể Rollback chéo server được. SAGA Pattern sinh ra để giải quyết việc này.

Cơ chế hoạt động: Cam kết và Đền bù

Thay vì ACID (Atomic), SAGA chấp nhận tính nhất quán cuối cùng (Eventual Consistency). Nguyên tắc: Nếu bước N thất bại, phải chạy ngược lại N-1 lệnh “Đền bù” (Compensating Transaction) để hoàn tác các bước N-1, N-2… đã thành công trước đó.

• Transaction T1: Trừ kho.
• Compensation C1: Cộng lại kho.

Nếu Payment lỗi, ta gọi C1 để cộng lại hàng vào kho.

2 Loại hình SAGA phổ biến

1. Choreography (Vũ điệu - Phi tập trung)

Các Service tự bắt chuyện với nhau qua Event Bus (Kafka/RabbitMQ). Không ai chỉ huy ai.

• Order bắn event: ORDER_CREATED.
• Inventory nghe ORDER_CREATED -> Trừ kho -> Bắn INVENTORY_DEDUCTED.
• Payment nghe INVENTORY_DEDUCTED -> Trừ tiền -> Bắn PAYMENT_PROCESSED.

Ưu điểm: Đơn giản, ít điểm nghẽn (bottleneck). Nhược điểm: Khi quy trình phức tạp, các service dính chùm sự kiện (Cyclic dependency), rất khó debug xem lỗi đang nằm ở đâu.

2. Orchestration (Nhạc trưởng - Tập trung)

Có một ông Saga Orchestrator Service (tương tự State Machine) đứng giữa điều phối.

• Orchestrator bảo Order: “Tạo đơn đi”. Order trả lời “Ok”.
• Orchestrator bảo Inventory: “Trừ kho đi”. Inventory trả lời “Ok”.
• Orchestrator bảo Payment: “Trừ tiền đi”. Payment trả lời “Lỗi rồi!”.
• Orchestrator bảo Inventory: “Thế thì cộng lại kho đi (Compensate)”.

Ưu điểm: Flow rõ ràng, dễ quản lý, dễ monitor. Nhược điểm: Ông Orchestrator trở thành điểm chết duy nhất (Single Point of Failure) nếu không thiết kế tốt.

Khi nào dùng SAGA?

Đừng dùng SAGA bừa bãi.

• Nếu nghiệp vụ đơn giản: Hãy cố gắng thiết kế sao cho nó nằm gọn trong 1 service.
• Sử dụng Two-Phase Commit (2PC) nếu cần nhất quán tức thì (nhưng hiệu năng kém).
• Chỉ dùng SAGA cho các nghiệp vụ dài (Long-running process) và chấp nhận độ trễ giữa các bước.

Kết luận

SAGA Pattern là kỹ thuật bắt buộc phải biết của Senior Backend Engineer. Nó phức tạp hóa code lên rất nhiều (bạn phải viết gấp đôi số logic: logic chạy xuôi và logic đền bù). Nhưng đó là cái giá phải trả để có được khả năng mở rộng (Scalability) của Microservices.