Tình huống thực tế

Vào giữa năm 2025, một startup fintech nhỏ tại TP.HCM đang mở rộng tích hợp thanh toán liên ngân hàng. Doanh nghiệp đã ký hợp tác với hai ngân hàng lớn và một ví điện tử phổ biến, nhưng mỗi giao dịch từ tài khoản ngân hàng sang ví đều phải đi qua một lớp trung gian duy nhất. Kết quả là đơn hàng bị treo 4–5 giây vào giờ cao điểm, còn đội kỹ thuật mất cả tuần chỉ để debug lỗi timeout.

Cánh cổng sắt thép ngày xưa

Trước đây, vai trò của integrator giống như người gác cổng duy nhất của tòa nhà. Mọi yêu cầu phải qua anh ta kiểm soát chìa khóa API. Khi lượng giao dịch tăng, cánh cổng trở thành điểm nghẽn: độ trễ tăng vọt, một lỗi nhỏ khiến toàn hệ thống dừng hoạt động. Đội ngũ vận hành vừa mệt mỏi vừa tự hào vì “kiểm soát được mọi thứ”, nhưng thực tế họ chỉ đang duy trì một điểm thất bại duy nhất.

Bàn tròn điều phối thay vì cổng

Hình ảnh thay đổi khi chuyển sang kiến trúc sự kiện. Thay vì một cánh cổng, các dịch vụ ngồi quanh bàn tròn và tự trao đổi qua tin nhắn. Không còn ai đứng giữa bắt buộc phê duyệt. Khi giao dịch liên ngân hàng diễn ra, sự kiện “đã trừ tiền” được phát ra, ví điện tử lắng nghe và tự cập nhật số dư, hệ thống kế toán cũng lắng nghe để ghi nhận. Không dịch vụ nào phải gọi trực tiếp dịch vụ khác.

Những thay đổi cụ thể cần thực hiện

Để chuyển từ cổng sang bàn tròn, đội ngũ phải thay đổi cách xây dựng hệ thống. Thay vì gọi API đồng bộ và chờ kết quả ngay, họ chuyển sang gửi tin nhắn bất đồng bộ. Một đơn hàng thanh toán chỉ cần được ghi nhận là “đã gửi yêu cầu” và tiếp tục chạy.

Thay vì một bộ điều phối tập trung, các dịch vụ tự sắp xếp theo kiểu múa rối — ai nhận được sự kiện thì xử lý việc đó. Để tránh hiểu sai, họ áp dụng contract testing và schema registry để mọi thay đổi cấu trúc tin nhắn đều được các bên nắm bắt ngay, thay vì để lỗi xuất hiện sau khi đã lên production.

Rủi ro lớn nhất nằm ở giai đoạn chuyển đổi nửa vời: cổng cũ đã tháo ra nhưng bàn tròn chưa hoạt động trơn tru, dẫn đến mất tích tin nhắn hoặc các dịch vụ không thống nhất về thứ tự sự kiện.

Ba câu hỏi để đội ngũ tự đánh giá

• Đội ngũ của bạn đang mong muốn kiểm soát hay sẵn sàng chia sẻ trách nhiệm?
• Khi một dịch vụ chậm, bạn muốn cả hệ thống chờ hay muốn các dịch vụ khác vẫn tiếp tục chạy?
• Bạn đang tối ưu cho “dễ debug khi có lỗi” hay cho “ít lỗi nhất có thể xảy ra”?