1) Problem Clarification / Làm rõ bài toán
EN
In microservices, a single business action (e.g., “Book Trip”, “Place Order”) spans multiple services.
We need distributed transactions to keep data consistent across services.
Two common approaches:
- Two-Phase Commit (2PC)
- Saga Pattern
VI
Trong microservices, một hành động (Ví dụ: “Đặt chuyến đi”, “Tạo đơn hàng”) liên quan nhiều service.
Cần transaction phân tán để dữ liệu không bị lệch.
Có hai mô hình phổ biến:
- Two-Phase Commit (2PC)
- Saga Pattern
2) Two-Phase Commit (2PC) — Overview / Tổng quan
EN
2PC = Distributed transaction across multiple participants using a central coordinator.
Steps:
- Prepare phase
Coordinator asks all services: “Can you commit?” - Commit phase
If all vote YES → commit
If any vote NO → rollback everywhere
VI
2PC là transaction phân tán có coordinator trung tâm.
Bước:
- Prepare
Coordinator hỏi tất cả service: “Có commit được không?” - Commit
Tất cả YES → commit
Một NO → rollback toàn bộ
3) 2PC – Strengths / Ưu điểm
EN
✔ Strong consistency
✔ ACID across distributed services
✔ Good for small-scale tightly coupled systems
VI
✔ Consistency mạnh
✔ ACID giữa nhiều service
✔ Hợp cho hệ thống nhỏ, tightly-coupled
4) 2PC – Weaknesses / Nhược điểm
EN
❌ Coordinator is single point of failure
❌ Participants locked until commit → performance bottleneck
❌ Network failures → blocking
❌ Does not scale well
VI
❌ Coordinator = single point of failure
❌ Các service bị khóa đến khi commit → choke performance
❌ Lỗi mạng dễ gây “blocking”
❌ Khó scale lớn
5) Saga Pattern — Overview / Tổng quan
EN
Saga breaks a large transaction into a sequence of local transactions executed by each service.
If any step fails → execute compensating transactions to undo previous effects.
VI
Saga chia transaction lớn thành chuỗi transaction nhỏ (local DB).
Nếu step nào fail → chạy compensating transaction để undo các bước trước.
6) Saga Flow Example / Ví dụ Saga
EN
Order Service → Payment Service → Inventory → Shipping
If Inventory fails:
→ run compensation in Payment (refund)
→ run compensation in Order (cancel)
VI
Order → Payment → Inventory → Shipping
Nếu Inventory fail:
→ Payment refund
→ Order cancel
7) Saga Types: Choreography vs Orchestration
EN
A) Choreography (event-driven)
Each service publishes events and listens for next-step events.
Pros: simple, loosely coupled
Cons: complex event spaghetti for large flows
B) Orchestration (central controller)
Saga orchestrator tells each service what to do next.
Pros: flow clear
Cons: orchestrator becomes dependency
VI
A) Choreography (điều phối bằng event)
Mỗi service publish event và service khác consume.
Ưu: đơn giản, loosely coupled
Nhược: dễ thành “mỳ spaghetti” event
B) Orchestration (điều phối trung tâm)
Một orchestrator điều khiển từng bước.
Ưu: flow rõ ràng
Nhược: orchestrator dễ thành điểm phụ thuộc
8) Saga – Strengths / Ưu điểm
EN
✔ Highly scalable
✔ No locks across services
✔ Fault tolerance with retries
✔ Works well with microservices
VI
✔ Scale tốt
✔ Không khoá xuyên service
✔ Chịu lỗi (retry/compensation)
✔ Phù hợp microservice
9) Saga – Weaknesses / Nhược điểm
EN
❌ Eventual consistency (not ACID)
❌ Compensating actions must be carefully designed
❌ Harder to debug and simulate
❌ Complex state transitions
VI
❌ Eventual consistency
❌ Compensate phải tự code (dễ sai)
❌ Debug khó
❌ State transition phức tạp
10) 2PC vs Saga — Comparison Table
EN
| Feature | 2PC | Saga |
|---|---|---|
| Consistency | Strong | Eventual |
| Scalability | Low | High |
| Latency | High | Low |
| Failure handling | Blocking | Retry/Compensate |
| Use case | Financial strict ACID | E-commerce, microservices |
| Complexity | Coordinator | Compensation logic |
VI
| Tiêu chí | 2PC | Saga |
|---|---|---|
| Consistency | mạnh | eventual |
| Scalability | kém | tốt |
| Latency | cao | thấp |
| Xử lý lỗi | blocking | retry + compensate |
| Use case | ngân hàng | e-commerce |
| Complexity | coordinator | code compensate |
11) When to use 2PC? / Khi nào dùng 2PC?
EN
Use only when:
✔ strict ACID required
✔ very low tolerance for inconsistent state
✔ small service footprint
Example: bank account ledger, critical core banking operations.
VI
Chỉ dùng khi:
✔ cần ACID tuyệt đối
✔ không được sai số
✔ hệ thống nhỏ
Ví dụ: ledger ngân hàng, core banking.
12) When to use Saga? / Khi nào dùng Saga?
EN
✔ microservices
✔ cross-domain workflows
✔ eventual consistency acceptable
✔ high throughput needed
✔ independent service ownership
VI
✔ microservices
✔ workflow nhiều domain
✔ chấp nhận eventual consistency
✔ throughput cao
✔ service tự quản lý
13) Practical Use Case Comparison
EN
Ticket booking / Flash sale → Saga
Ride sharing trip creation → Saga
Bank fund transfer → 2PC or strongly consistent ledger
E-commerce order flow → Saga orchestration
VI
Đặt vé / Flash sale → Saga
Tạo chuyến đi (Grab/Uber) → Saga
Chuyển tiền ngân hàng → 2PC / ledger ACID
Luồng order e-commerce → Saga orchestration
14) Failure Handling in Saga / Saga xử lý lỗi
EN
- retry with backoff
- compensation
- mark transaction as FAILED final state
- manual reconciliation for corner-cases
VI
Saga xử lý:
- retry
- compensate
- đánh dấu FAILED
- đối soát thủ công khi lỗi hiếm
15) Summary / Tóm tắt
EN
2PC = consistency first, poor scalability
Saga = scalability first, eventual consistency
Choice depends on business requirement:
- Do we allow temporary inconsistency?
- Can we build proper compensating logic?
- What throughput is required?
VI
2PC = ưu tiên consistency, scale kém
Saga = ưu tiên scale, consistency eventual
Chọn dựa vào yêu cầu business:
- Có cho phép sai lệch tạm thời?
- Có viết được compensate logic?
- Throughput cần đến mức nào?
[…] SAGA Pattern vs Two-Phase Commit (2PC) In Distributed Transactions […]