Khi một workflow tự động hóa cập nhật nhiều hệ thống, transaction cơ sở dữ liệu truyền thống thường không thể rollback tất cả dịch vụ cùng lúc. Saga chia quy trình thành các bước có trạng thái rõ ràng và định nghĩa compensation cho từng bước đã hoàn tất, giúp phục hồi có kiểm soát thay vì để dữ liệu dở dang.
Saga là gì và khi nào nên dùng?
Saga là chuỗi transaction cục bộ. Nếu một bước sau thất bại, workflow chạy compensation theo thứ tự ngược để đưa hệ thống về trạng thái nghiệp vụ chấp nhận được. Saga phù hợp khi quy trình đi qua nhiều service, API, hàng đợi hoặc hệ thống không hỗ trợ transaction phân tán; mục tiêu là nhất quán cuối cùng và đường phục hồi minh bạch.
Saga choreography và orchestration khác nhau thế nào?
Choreography để service phản ứng bằng sự kiện, phù hợp luồng đơn giản. Orchestration dùng một orchestrator quản lý thứ tự, timeout và compensation, dễ quan sát và kiểm thử hơn khi có nhiều nhánh hoặc yêu cầu audit.
Thiết kế transaction cục bộ và compensation
Mỗi bước cần điều kiện đầu vào, thay đổi cục bộ, sự kiện đầu ra và compensation. Compensation không luôn là undo kỹ thuật: email đã gửi có thể cần thông báo đính chính hoặc nhiệm vụ cho người xử lý. Bước không thể đảo ngược phải được đánh dấu rõ.
Trạng thái Saga và tính nhất quán
Nên phân biệt pending, running, compensating, compensated, completed, failed và needs_review. Lưu event_id, saga_id, step_name, attempt_count, thời điểm và nguyên nhân. Outbox giúp phát sự kiện an toàn, còn idempotency ngăn tác động lặp.
Retry, timeout và compensation phối hợp ra sao?
Retry chỉ dành cho lỗi tạm thời và phải nằm trong deadline toàn Saga. Khi hết retry hoặc deadline, chuyển sang compensation. Nếu timeout nhưng kết quả phía đích chưa rõ, hãy truy vấn trạng thái hoặc dùng idempotency key trước khi bù trừ. Đọc thêm retry với exponential backoff và jitter, timeout và deadline trong workflow và idempotency chống chạy trùng.
Compensation có thể thất bại thì làm gì?
Compensation cũng có thể lỗi nên cần retry có giới hạn, hàng đợi riêng và trạng thái needs_review. Không che giấu thất bại dưới trạng thái đã rollback. Sự kiện không thể xử lý tiếp nên chuyển vào dead-letter queue cùng metadata để điều tra.
Quy trình xây dựng Saga thực tế
Vẽ các bước và điểm irreversible; chọn choreography hoặc orchestration; định nghĩa transaction, sự kiện và compensation; thiết kế state machine; gắn saga_id, event_id và idempotency key; đặt timeout, deadline và retry budget; ghi audit log; kiểm thử duplicate event, timeout không rõ kết quả và compensation thất bại.
Các lỗi thiết kế thường gặp
Đừng coi Saga là rollback nguyên tử. Tránh bỏ compensation cho tác động bên ngoài, chỉ lưu trạng thái cuối, retry vô hạn, không phân biệt timeout với thất bại chắc chắn, hoặc đặt bước irreversible quá sớm mà không có phê duyệt.
Checklist trước production
Mỗi bước có transaction cục bộ và compensation rõ ràng; bước irreversible có nhánh riêng; state machine phân biệt completed, compensating, compensated, failed và needs_review; có saga_id, event_id, idempotency key, audit log, DLQ và dashboard; đã kiểm thử worker dừng giữa chừng và duplicate event.
Câu hỏi thường gặp
Saga có nhất quán ngay lập tức không? Không, Saga hướng tới nhất quán cuối cùng. Compensation có luôn hoàn tác chính xác không? Không, một số tác động cần hành động nghiệp vụ thay thế. Nên dùng Saga hay transaction cơ sở dữ liệu? Dùng transaction trong cùng database, Saga khi đi qua nhiều service. Khi nào cần DLQ? Khi lỗi không thể tiếp tục sau retry hoặc cần người vận hành điều tra.
Kết luận
Saga biến workflow nhiều hệ thống thành chuỗi bước có trạng thái, audit và đường compensation rõ ràng. Kết hợp transaction cục bộ, idempotency, deadline, retry có giới hạn và DLQ giúp doanh nghiệp phục hồi lỗi mà không phụ thuộc rollback nguyên tử.