Kiến trúc hướng sự kiện cho Cloud-Native Banking: Những bài học thực chiến

Trong bối cảnh chuyển đổi số ngân hàng, việc áp dụng Kiến trúc hướng sự kiện (Event-Driven Architecture - EDA) đang trở nên phổ biến, đặc biệt là với các hệ thống Cloud-native. Tuy nhiên, việc triển khai kiến trúc này trong một môi trường được kiểm soát chặt chẽ như ngân hàng hay tài chính lại đầy rẫy những thách thức riêng biệt.

Chris Tacey-Green, Trưởng bộ phận Kỹ thuật tại Investec, đã chia sẻ những kinh nghiệm thực tế ("battle-tested") về việc xây dựng EDA trong ngành tài chính, từ những lợi ích to lớn cho đến những "cái đau" (what hurts) mà các kỹ sư phải đối mặt và cách giải quyết chúng.

Kiến trúc hệ thống thanh toán hiện đại

Sự khác biệt cơ bản: Lệnh (Command) và Sự kiện (Event)

Trước khi đi sâu vào triển khai, cần phân biệt rõ ràng hai khái niệm thường bị nhầm lẫn:

• Command (Lệnh): Là yêu cầu thực hiện một hành động cụ thể. Người gửi sẽ chờ đợi kết quả trả về. Ví dụ: "Chuyển tiền cho tôi".
• Event (Sự kiện): Là thông báo về một sự thay đổi trạng thái đã xảy ra. Người gửi không mong đợi phản hồi hay hành động nào từ phía người nhận. Ví dụ: "Tiền đã được chuyển".

Việc hiểu rõ sự khác biệt này là chìa khóa để tránh việc thiết kế sai hệ thống, biến kiến trúc bất đồng bộ thành một hệ thống đồng bộ phức tạp và kém hiệu quả.

Tại sao chọn Event-Driven Architecture trong Ngân hàng?

1. Giải phóng kết nối (Decoupling)

Trong ngân hàng, các hệ thống như Thanh toán (Payments) và Giám sát giao dịch (Transaction Monitoring) có các yêu cầu về độ tin cậy và tốc độ khác nhau. Nếu kết nối chặt chẽ giữa chúng, sự cố ở hệ thống giám sát có thể làm tê liệt hệ thống thanh toán. Sử dụng sự kiện cho phép hệ thống thanh toán chỉ cần "shout" (phát đi) sự kiện giao dịch, không cần biết ai đang lắng nghe hay xử lý nó.

2. Nhật ký hoạt động bất biến (Immutable Activity Log)

EDA cung cấp một luồng nhật ký tự nhiên của mọi thay đổi trạng thái. Thay vì phụ thuộc vào các file log riêng biệt khó đọc, hệ thống có thể dựa vào chính dòng sự kiện để tái hiện lại toàn bộ lịch sử của một giao dịch, từ khi khởi tạo, kiểm tra gian lận cho đến khi hoàn tất.

3. Khả năng chịu lỗi (Fault Tolerance)

Trong môi trường Cloud-native, sự cố là điều tất yếu. EDA cho phép xử lý lỗi ở 3 cấp độ:

• Retry cục bộ: Thử lại ngay trong code.
• Back-off bằng công nghệ sự kiện: Cấu hình retry trên nền tảng message broker (Kafka, Kinesis...) với khoảng thời gian chờ dài hơn.
• Dead Letter (Hàng thư từ chối): Khi mọi thứ đều thất bại, sự kiện được chuyển vào hàng đợi đặc biệt để cảnh báo cho con người can thiệp thủ công, tránh việc lặp lại vô tận gây nghẽn hệ thống.

Những thách thức và giải pháp

1. Đào tạo con người và Văn hóa

Kiến trúc này khó khăn cho những kỹ sư chưa từng làm việc với nó. Thời gian onboard có thể lên đến 6 tháng.

• Giải pháp: Xây dựng Developer Platform (nền tảng cho nhà phát triển) với các "Paved Roads" (con đường trải sẵn) và template chuẩn. Đào tạo thực tế (hands-on) thay vì chỉ lý thuyết.

2. Mất dữ liệu hoặc Trùng lặp sự kiện

Trong ngân hàng, việc mất sự kiện chuyển tiền là thảm họa, nhưng việc gửi tiền hai lần cũng không kém phần nghiêm trọng.

• Mẫu Outbox Pattern (Người gửi): Để tránh mất mát, khi lưu trạng thái vào database (ví dụ: tạo khách hàng), ta cùng lúc lưu sự kiện vào bảng "Outbox" trong cùng một transaction. Một quy trình riêng (Dispatcher) sẽ đọc từ Outbox và gửi đi tới message broker.
• Mẫu Inbox Pattern (Người nhận): Để tránh trùng lặp (do cơ chế "at-least-once" của message broker), người nhận sẽ ghi sự kiện vào bảng "Inbox" và kiểm tra ID duy nhất trước khi xử lý logic nghiệp vụ.

"Hãy xây dựng Inbox và Outbox vào framework của bạn ngay từ đầu để các đội ngũ không phải tự thiết kế lại bánh xe và tránh rơi vào tình trạng 'chuyển tiền hai lần'."

3. Quản lý hợp đồng sự kiện (Event Contracts)

Sự kiện là một hợp đồng công khai. Một khi đã xuất bản, bạn không thể lấy lại hay thay đổi nó vì các hệ thống khác có thể đang tiêu thụ dòng sự kiện lịch sử đó.

• Giải pháp: Coi sự kiện như một API Contract. Hạn chế tối đa các thay đổi phá vỡ (breaking change). Nếu cần thay đổi cấu trúc dữ liệu, hãy sử dụng Versioning (định phiên bản) sự kiện tương tự như API v1, v2...

4. Thứ tự của sự kiện (Event Ordering)

Hầu hết các công nghệ Cloud-native eventing đều không đảm bảo thứ tự sự kiện để tối ưu hóa tốc độ xử lý.

• Giải pháp: Nếu nghiệp vụ yêu cầu thứ tự nghiêm ngặt (ví dụ: xử lý lệnh rút tiền phải theo thứ tự thời gian), bạn có thể:
  • Sử dụng Event Versioning đánh số thứ tự (1, 2, 3...) trên từng sự kiện của một đối tượng (aggregate) và kiểm tra logic tại Consumer.
  • Sử dụng Implicit Ordering (Thứ tự ngầm định) thông qua validate nghiệp vụ (ví dụ: không thể thanh toán cho người thụ hưởng nếu người đó chưa được tạo ra).

Tổng kết

Triển khai kiến trúc hướng sự kiện trong ngân hàng không chỉ là chuyện công nghệ mà còn là bài toán về quy trình, đào tạo và kỷ luật trong thiết kế. Sự kết hợp giữa các mẫu thiết kế Inbox/Outbox, versioning cẩn thận và một nền tảng phát triển nội bộ mạnh mẽ sẽ giúp doanh nghiệp tận dụng được sức mạnh của Cloud-native mà vẫn đảm bảo sự an toàn và chính xác tuyệt đối cho dòng tiền.