Phần 4: Saga Pattern: Giao Dịch Phân Tán Không Cần 2PC

Phần 4: Saga Pattern: Giao Dịch Phân Tán Không Cần 2PC

🇬🇧 Read the English version on tanhdev.com ← Chương trước: Phần 3: Event Sourcing & CQRS | Mục lục Series | Chương tiếp theo: Phần 5: ISO 20022 & Payment Gateways → Answer-first: Saga Pattern thay thế giao thức Two-Phase Commit (2PC) trong microservices ngân hàng bằng chuỗi các giao dịch cục bộ phối hợp qua Temporal Workflow hoặc Kafka, kèm cơ chế giao dịch bù trừ (Compensating Transactions) và Dead Letter Queue khi xảy ra sự cố. ...

18 tháng 6, 2026 · 10 phút · Lê Tuấn Anh
Sharded MySQL vs TiDB NewSQL Distributed ACID and Scale-Out Architecture

Sharded MySQL (Vitess) vs. TiDB NewSQL: ACID Phân Tán & Thuế Độ Trễ Mạng

← Chương trước: Phần 4: MariaDB vs. MySQL | Mục lục Series | Chương tiếp theo: Phần 6: Apache Kafka vs. NATS JetStream → Sharded MySQL (Vitess) vs. TiDB NewSQL: ACID Phân Tán & Thuế Độ Trễ Mạng Answer-first: Sharded MySQL (Vitess) áp đảo về độ trễ ghi (sub-2ms) và cô lập lỗi (Blast Radius) cho hệ thống E-commerce / SaaS có Sharding Key sạch. Ngược lại, TiDB NewSQL là giải pháp cứu cánh cho schema phức tạp nhờ cơ chế tự động chia tách Region 96MB, chấp nhận mức sàn độ trễ ghi 8–15ms do Percolator 2PC. ...

21 tháng 8, 2026 · 12 phút · Lê Tuấn Anh
Saga Pattern Là Gì? Giao Dịch Phân Tán Với Temporal & Go

Saga Pattern Là Gì? Giao Dịch Phân Tán Với Temporal & Go

🇬🇧 Read the English version on tanhdev.com ← Chương trước: Thiết Kế API Lũy Đẳng (Idempotent API) — Khóa Lũy Đẳng, Middleware SetNX & Mẫu Stripe | Mục lục Series | Chương tiếp theo: Băm Nhất Quán (Consistent Hashing) — Node Ảo, Phương Sai Tải & Vòng CRC32 Trong Go → Answer-first: Saga Pattern là mô hình quản lý giao dịch phân tán trong microservices bằng cách chia nhỏ thành chuỗi giao dịch cục bộ (local transactions). Khi một bước thất bại, hệ thống tự động kích hoạt chuỗi hành động bù trừ (compensating transactions) theo thứ tự ngược LIFO để khôi phục tính nhất quán cuối cùng mà không cần dùng khóa phân tán 2PC. ...

18 tháng 6, 2026 · 11 phút · Lê Tuấn Anh
Temporal Saga Pattern in Golang Distributed Transactions

Triển khai Giao dịch Phân tán trong Go với Temporal Saga Pattern

Answer-first: Temporal Saga Pattern trong Go giải quyết giao dịch phân tán FinTech thay thế 2PC chặn khóa. Bộ điều phối Workflow lưu trạng thái tất định, tự động kích hoạt chuỗi bù trừ đảo ngược khi có lỗi hạ tầng, bảo toàn nguyên lý sổ kép SUM(Debits)=SUM(Credits) và ngăn ngừa trùng lặp nhờ Idempotency Key. 🇬🇧 Read the English version of this article on tanhdev.com 🏛️ Bài viết này thuộc chuyên đề thiết kế hệ thống giao dịch phân tán chịu tải cao. Xem thêm tại Series Thiết Kế Hệ Thống Phân Tán High-Concurrency. ...

23 tháng 7, 2026 · 25 phút · Lê Tuấn Anh
Orchestrated Saga Pattern với Temporal Go SDK trong FinTech Microservices

Orchestrated Saga Pattern Với Temporal Go SDK Trong FinTech Microservices

Answer-first: Orchestrated Saga Pattern với Temporal Go SDK quản lý giao dịch phân tán FinTech bằng bộ điều phối tập trung Event Sourcing Replay, lưu trữ lịch sử tất định (deterministic), thực thi bù trừ LIFO qua Disconnected Context khi xảy ra lỗi, và ngăn chặn giao dịch trùng lặp bằng Idempotency Key kèm Transactional Outbox. 📌 Thông Báo Chuyển Hướng / Consolidation: Bài viết này đã được hợp nhất và mở rộng đầy đủ phiên bản kiến trúc 2026 tại: Triển khai Giao dịch Phân tán trong Go với Temporal Saga Pattern. ...

17 tháng 7, 2026 · 13 phút · Lê Tuấn Anh
Hướng Dẫn Dapr Workflow Go: Orchestrated Saga Pattern

Hướng Dẫn Dapr Workflow Go: Orchestrated Saga Pattern

Answer-first: Dapr Workflow cung cấp mô hình Orchestrated Saga bền vững (Durable Execution) cho các microservices Golang. Bằng cách tập trung hóa máy trạng thái, tự động bù trừ khi xảy ra sự cố và loại bỏ phụ thuộc vào Two-Phase Commit (2PC), giải pháp duy trì tính nhất quán cuối cùng cho giao dịch tài chính đa bước. 🇬🇧 Read the English version of this article on tanhdev.com Hầu hết các lập trình viên Go xây dựng microservices đều biết đến mẫu Choreography Saga: service A phát ra (emit) một sự kiện, service B phản ứng, service C phản ứng với B, và cứ tiếp tục như vậy. Nếu bước C thất bại, các services sẽ phát ra các sự kiện “bù trừ” (compensation) theo thứ tự ngược lại. Mẫu này hoạt động một cách mượt mà đối với các luồng đơn giản, nhưng lại phá vỡ tính hiệu quả khi số lượng bước tăng lên: việc debug một saga thất bại đòi hỏi phải lần theo dấu vết (tracing) các sự kiện qua năm topic của message broker, và việc triển khai logic bù trừ đòi hỏi mỗi service phải hiểu toàn bộ trạng thái của saga. ...

1 tháng 6, 2026 · 18 phút · Lê Tuấn Anh