CQRS

← Chương trước: Phần 2: Distributed SQL ACID Latency | Mục lục Series | Chương tiếp theo: Phần 4: Saga Pattern Giao Dịch Phân Tán → Answer-first: Kết hợp Event Sourcing và CQRS trong Core Banking giúp lưu trữ toàn bộ lịch sử biến động tài khoản dưới dạng chuỗi sự kiện bất biến, tách biệt luồng ghi giao dịch khỏi luồng đọc số dư để đạt độ trễ truy vấn dưới 1ms. ...

📖 Bản tiếng Anh (English Edition) Yêu cầu tiên quyết: Đọc Phần 3: Giao Dịch ACID & Concurrency để hiểu cơ chế cô lập cơ sở dữ liệu. Phần 4: Kiến Trúc Core Banking Hiện Đại & Event-Driven Tóm tắt cốt lõi: Hiện đại hóa các khối monolith ngân hàng lõi đòi hỏi chuyển dịch sang kiến trúc microservices hướng sự kiện dựa trên ba mẫu thiết kế cốt lõi: Event Sourcing, CQRS và Orchestrated Saga. Việc ghi nhận mọi biến động số dư thành các sự kiện nghiệp vụ bất biến giúp hệ thống đạt khả năng mở rộng độc lập, cung cấp dấu vết kiểm toán tài chính hoàn hảo và phản hồi truy vấn số dư tức thì dưới 1ms mà không bị giới hạn bởi cơ chế Two-Phase Commit (2PC) nghẽn mạng. ...

Answer-first: Hệ thống Event-Driven hiệu năng cao trên Go kết hợp NATS JetStream, CQRS và Transactional Outbox Pattern xử lý hơn 120.000 event/giây. Thiết kế phân tách Command-Query triệt để, đảm bảo ngữ nghĩa At-Least-Once Delivery và duy trì tính nhất quán cuối cùng giữa các bounded context. 🇬🇧 Read the English version of this article on tanhdev.com 1. Lý do Kiến trúc: Tại sao chọn Go + NATS JetStream cho Microservices Event-Driven Trong các kiến trúc Cloud-Native hiện đại, việc mở rộng quy mô hệ thống phân tán vượt ngưỡng hàng chục nghìn giao dịch mỗi giây (TPS) bộc lộ những nút thắt cổ chai nghiêm trọng trong mô hình request-response truyền thống. Các microservices truyền thống được xây dựng xoay quanh giao thức đồng bộ HTTP/REST hoặc gRPC thường xuyên đối mặt với hiện tượng tranh chấp ghi cơ sở dữ liệu (database write contention), cạn kiệt connection pool, và hiệu ứng tuyết lở (cascading latency spikes) mỗi khi có các đợt bùng nổ lưu lượng truy cập dội xuống tầng lưu trữ. Khi một cơ sở dữ liệu duy nhất phải gánh vác đồng thời cả các transaction cập nhật dữ liệu phức tạp (commands) lẫn các truy vấn đọc phân tích nặng nề (reads), hiện tượng khóa cấp dòng (row-level locks) và chi phí duy trì index sẽ làm nghẽn thông lượng, đẩy độ trễ p99 từ vài mili-giây vọt lên hàng giây. ...