Event-Driven

← Chương trước: Phần 1 — Nền tảng: Microservices & GitOps (2026) | Mục lục Series | Chương tiếp theo: Phần 3 — Data Layer: Chuyển đổi từ Aurora sang TiDB (2026) → Answer-first: Hệ thống Event-Driven của PayPay sử dụng Apache Kafka làm xương sống truyền tải thông điệp, kết hợp mẫu hình Saga, Transactional Outbox và cơ chế Dead Letter Queue để xử lý tải đột biến và đảm bảo tính nhất quán dữ liệu giao dịch. ...

← Chương trước: Mở Rộng Cơ Sở Dữ Liệu & Tối Ưu Bể Kết Nối — Sharding, TiDB & PostgreSQL | Mục lục Series | Chương tiếp theo: Khóa Phân Tán (Distributed Locks) — Toán Học Redlock, etcd Raft & Chống Chia Cắt Mạng → Answer-first: Kiến trúc Event-Driven với Apache Kafka tận dụng cơ chế zero-copy sendfile và sparse index để đạt throughput hàng triệu msg/s. Trong Go, mô hình Bounded Worker Pool tạo áp lực ngược (backpressure) tự nhiên và xử lý tuần tự theo partition, đảm bảo ngữ nghĩa exactly-once cho các luồng thanh toán. ...

← Chương trước: Phần 3 — Giao dịch ACID & Concurrency trong Core Banking | Mục lục Series | Chương tiếp theo: Phần 5 — Tiêu chuẩn Core Banking ISO 8583 & ISO 20022 → Answer-first: Kiến trúc Core Banking hiện đại chuyển đổi từ Monolith sang Microservices hướng sự kiện (Event-Driven): áp dụng Event Sourcing cho Sổ Cái bất biến, CQRS phân tách luồng ghi ACID và đọc tốc độ cao, Saga Pattern điều phối giao dịch phân tán và Transactional Outbox đảm bảo chuyển phát sự kiện an toàn At-Least-Once. ...

← Chương trước: Phần 6: Giai Đoạn 1 — Strangler Fig Read-Only | Mục lục Series | Chương tiếp theo: Phần 8: Giai Đoạn 3 — Full Cutover Zero Downtime → Answer-first: Giai đoạn 2 kích hoạt API ghi trên hệ thống Go microservice song song với Magento nhờ cơ chế Dual-Write bất đồng bộ qua Dapr Pub/Sub và Transactional Outbox, có cờ tính năng (feature flags) và phân xử xung đột dữ liệu tự động. ...

Answer-first: Kiến trúc đọc vị khách hàng 15 giây tích hợp Edge Ingestion, Vector Search nhúng trong bộ nhớ và Feature Store siêu nhẹ. Hệ thống tính toán sở thích thời gian thực, dự đoán giỏ hàng và định tuyến ưu đãi trước khi khách hoàn tất thao tác duyệt, tăng tỷ lệ checkout thành công 22%. Cuộc đua Quick Commerce (Q-Commerce) giao hàng siêu tốc trong 15-30 phút đã chính thức chạm ngưỡng giới hạn. Như chuyên gia tăng trưởng Lê Thanh Hải (Henry) đã nhận định trên LinkedIn, các nền tảng không thể yêu cầu tài xế chạy nhanh hơn nữa mà không phá vỡ Unit Economics (Hiệu quả kinh tế trên từng đơn vị) hoặc gây rủi ro an toàn. ...

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. Traditional microservices built around synchronous HTTP/REST or gRPC backplanes frequently encounter database write contention, connection pool exhaustion, and cascading latency spikes whenever traffic bursts hit downstream storage layers. When a single database handles both complex mutation transactions (commands) and heavy analytical join queries (reads), row-level locks and index maintenance stall throughput, inflating p99 latencies from milliseconds to seconds. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Kiến trúc Hướng sự kiện với Dapr Pub/Sub giải quyết bài toán nhất quán dữ liệu liên service khi chia tách Monolith thành 21+ Microservices. Hệ thống áp dụng quy ước đặt tên 3 phân đoạn ({service}.{entity}.{action}), Saga pattern với giao dịch bù trừ (Compensating Transactions), xử lý người nhận lũy đẳng (Idempotent Consumers) và Dead Letter Queues (DLQ). Trong bài viết trước, chúng ta đã khám phá cách việc từ bỏ kiến trúc nguyên khối (monolithic) để ưu tiên các ranh giới ngữ cảnh nghiêm ngặt của Thiết kế Hướng Domain (Domain-Driven Design - DDD) đã giúp một nền tảng thương mại điện tử có thể scale vượt mức 10.000+ đơn hàng mỗi ngày. Tuy nhiên, việc băm nát một database khổng lồ thành 20+ database Postgres hoàn toàn cách ly lại sinh ra một vấn đề mới cực kỳ đáng sợ: Làm thế nào để chúng ta duy trì tính nhất quán dữ liệu giữa các service đã bị cắt đứt kết nối với nhau? Khám phá thêm tại series High Concurrency Systems và System Design. ...