Kiến trúc hướng sự kiện

Event-Driven Architecture (EDA) là gì?

Event-Driven Architecture là mẫu thiết kế hệ thống phân tán trong đó dòng chảy chương trình được điều khiển bởi sự kiện (event) – ví dụ: TransferCompleted, LoginFailed, FraudDetected. Mỗi event chứa thông tin về sự thay đổi trạng thái (state change) và được publish lên một event broker trung gian. Các consumer quan tâm sẽ subscribe và xử lý bất đồng bộ (asynchronously), tạo nên khả năng mở rộng theo chiều ngang vượt trội so với mô hình request-response truyền thống.

Ba thành phần chính

• Event Producer: microservice phát sinh sự kiện (ví dụ: Payment-Service publish PaymentInitiated).
• Event Broker / Streaming Platform: trung gian lưu trữ và phân phối event – Apache Kafka (de-facto chuẩn, xử lý 7+ nghìn tỷ message/ngày tại LinkedIn), RabbitMQ, Pulsar, AWS Kinesis, Google Pub/Sub.
• Event Consumer: service subscribe topic, xử lý logic nghiệp vụ tương ứng (Notification-Service gửi SMS, Audit-Service ghi log, Analytics-Service cập nhật dashboard).

Hai mô hình chính

• Pub/Sub (Publish/Subscribe): one-to-many, event broadcast đến nhiều consumer độc lập, phù hợp notification, real-time dashboard.
• Event Sourcing: lưu trữ toàn bộ lịch sử sự kiện thay vì chỉ trạng thái hiện tại, giúp audit trail đầy đủ và replay được mọi giao dịch – rất phù hợp yêu cầu truy vết của NHNN.

Ứng dụng điển hình trong ngân hàng

• Phát hiện gian lận thời gian thực: phân tích stream giao dịch thẻ, phát hiện bất thường (giao dịch lúc 2h sáng, tại quốc gia lạ) trong < 100ms.
• Xử lý thanh toán liên ngân hàng: Napas 24/7 dùng message queue đảm bảo không mất giao dịch khi một hệ thống downtime.
• Cập nhật số dư real-time: mỗi giao dịch sinh event, mọi kênh (mobile, web, ATM) đồng bộ tức thì.
• Audit & Compliance: tuân thủ Thông tư 17/2024/TT-NHNN về giám sát an toàn hoạt động, mọi event được log immutable trên Kafka log.

Ví dụ cụ thể

Khi khách hàng Techcombank chuyển 5 triệu qua MoMo: Transfer-Service publish event TransferCompleted{from, to, amount, timestamp} lên Kafka. Đồng thời: (1) SMS-Service gửi OTP/biên nhận, (2) Fraud-AI đánh giá rủi ro, (3) DataLake-Service đẩy vào data warehouse cho BI, (4) Ledger-Service cập nhật sổ cái – tất cả chạy song song, không blocking.

Thách thức

Đảm bảo event ordering trong phân vùng (partition), idempotency (xử lý trùng lặp event), exactly-once semantics, và khả năng monitoring toàn trình (distributed tracing với OpenTelemetry) là những bài toán kỹ thuật phức tạp đòi hỏi đội ngũ có kinh nghiệm.