Bạn đã bao giờ đặt một đơn hàng online và ngồi nhìn màn hình quay vòng cả phút chưa? Đó không phải vấn đề về tốc độ mạng – mà có thể là dấu hiệu của một hệ thống thiết kế tệ. Kiểu hệ thống mà mọi thứ phải “xong xuôi hết” trước khi người dùng nhận được phản hồi. Trong thời đại mà tốc độ và khả năng mở rộng quyết định thành bại, Kiến trúc Hướng Sự kiện (EDA) đang dần trở thành tiêu chuẩn mới.

Bài viết này không lý thuyết suông. Chúng ta sẽ đi thẳng vào vấn đề: Vì sao cách làm cũ không còn hiệu quả, và EDA đã thay đổi cuộc chơi như thế nào.

Đặt vấn đề

Hãy tưởng tượng một quy trình xử lý đơn hàng đơn giản. Khi người dùng nhấn "Đặt hàng", hệ thống của chúng ta (gọi là Order Service) phải thực hiện một loạt các tác vụ tuần tự:

1. Gọi Payment Service để xử lý thanh toán.
2. Gọi Inventory Service để trừ số lượng hàng trong kho.
3. Gọi Shipping Service để yêu cầu giao hàng.
4. Gọi Notification Service để gửi email xác nhận cho khách.
5. Cuối cùng, trả về phản hồi "Thành công!" cho người dùng.

Đoạn code minh họa của chức năng đặt hàng này như sau

public class OrderService { private PaymentService paymentService; private InventoryService inventoryService; private ShippingService shippingService; private NotificationService notificationService; public OrderService(PaymentService paymentService, InventoryService inventoryService, ShippingService shippingService, NotificationService notificationService) { this.paymentService = paymentService; this.inventoryService = inventoryService; this.shippingService = shippingService; this.notificationService = notificationService; } public String placeOrder(OrderData orderData) { String orderId = createOrderRecord(orderData); // Gọi từng service tương ứng PaymentResponse paymentResponse = paymentService.charge(orderId, orderData.getTotal()); InventoryResponse inventoryResponse = inventoryService.reserve(orderId, orderData.getItems()); ShippingResponse shippingResponse = shippingService.sendShippingInformation(orderId, orderData); NotificationResponse notificationResponse = notificationService.alert(orderId, orderData); return orderId; } private String createOrderRecord(OrderData orderData) { // TODO: implement logic to persist order return UUID.randomUUID().toString(); // tạm dùng UUID để mô phỏng ID đơn hàng }
}

Đây là kiến trúc đồng bộ (Synchronous) kinh điển, và nó đi kèm một số "pain points" có thể kể đến như:

• Phụ thuộc chặt chẽ (Tightly Coupled): Order Service phải biết về địa chỉ, cách giao tiếp với 4 services kia. Nếu một trong số chúng thay đổi, Order Service có nguy cơ sẽ cập nhật theo.
• Hiệu ứng domino (Cascading Failures): Chỉ cần Notification Service bị lỗi hoặc phản hồi chậm, toàn bộ quá trình sẽ bị treo. Người dùng có thể đã bị trừ tiền nhưng cuối cùng lại nhận về thông báo lỗi. Đây chính là một điểm lỗi gây tê liệt cả hệ thống, hay thuật ngữ chuyên ngành gọi là SPoF (single point of failure).
• Ảnh hưởng trải nghiệm Clients: Người dùng phải chờ đợi cho đến khi tất cả các bước hoàn tất. Thời gian chờ bằng tổng thời gian thực thi của tất cả các dịch vụ cộng lại.
• Khó mở rộng: Nếu lượng đơn hàng tăng đột biến làm Payment Service quá tải, toàn bộ hệ thống sẽ chậm lại theo.

Hàng đợi và kiến trúc Asynchronous

Để giải quyết vấn đề chờ đợi và đổ vỡ dây chuyền, có một giải pháp là sử dụng hàng đợi (Message Queue).

Thay vì gọi trực tiếp, Order Service giờ đây chỉ cần làm một việc duy nhất: tạo một "yêu cầu xử lý đơn hàng" và đẩy nó vào một cái hộp thư trung gian (Queue). Sau đó, nó ngay lập tức báo cho người dùng: "Chúng tôi đã tiếp nhận đơn hàng của bạn!".

Lúc này, hàm xử lí đơn hàng của Order Service sẽ thành như sau

public class OrderService { private MessageQueue paymentQueue; private MessageQueue inventoryQueue; private MessageQueue shippingQueue; private MessageQueue notificationQueue; public OrderService(MessageQueue paymentQueue, MessageQueue inventoryQueue, MessageQueue shippingQueue, MessageQueue notificationQueue) { this.paymentQueue = paymentQueue; this.inventoryQueue = inventoryQueue; this.shippingQueue = shippingQueue; this.notificationQueue = notificationQueue; } public String placeOrder(OrderData orderData) { String orderId = createOrderRecord(orderData); // Gửi message tới các queue tương ứng paymentQueue.send(Map.of( "action", "charge", "order_id", orderId, "amount", orderData.getTotal() )); inventoryQueue.send(Map.of( "action", "reserve", "order_id", orderId, "items", orderData.getItems() )); shippingQueue.send(Map.of( "action", "send_shipping_information", "order_id", orderId, "data", orderData )); notificationQueue.send(Map.of( "action", "alert", "order_id", orderId, "data", orderData )); return orderId; } private String createOrderRecord(OrderData orderData) { // TODO: Implement persistence logic return UUID.randomUUID().toString(); // Mô phỏng ID đơn hàng }
}

Các dịch vụ Payment, Inventory... sẽ lắng nghe từ Queue này, và khi có tin nhắn mới, chúng sẽ tự lấy ra và xử lý công việc của mình. Cách tiếp cận này mang lại một số lợi ích như:

• Phản hồi nhanh: Trải nghiệm người dùng được cải thiện đáng kể.
• Linh hoạt hơn (Resilience): Nếu Shipping Service tạm thời gián đoạn, tin nhắn vẫn nằm an toàn trong Queue và sẽ được xử lý khi dịch vụ này hoạt động trở lại.
• Giảm sự phụ thuộc (Loose Coupling): Order Service không còn cần biết địa chỉ của các dịch vụ kia.

Tuy nhiên, khi hệ thống phức tạp hơn, cách làm này bộc lộ những hạn chế mới:

• Logic vẫn còn tập trung: Order Service vẫn phải "biết" rằng nó cần tạo ra các tin nhắn cho các tác vụ cụ thể. Nếu có thêm một service mới, ví dụ Report Service - nhận thông tin về đơn hàng để tổng hợp báo cáo, chúng ta lại phải sửa code của Order Service để đẩy thêm tin nhắn vào một queue khác cho service mới này.
• Hạn chế "one-one": Một tin nhắn trong Queue thường chỉ được xử lý bởi một người nhận (consumer). Nếu chúng ta muốn cả Shipping Service và Notification Service cùng xử lí sau khi đơn hàng được thanh toán thành công, chúng ta phải làm thế nào?

Event-Driven Architecture

Đây là lúc chúng ta cần một sự thay đổi trong hệ thống: từ "yêu cầu" (command) sang "thông báo" (event)

Thay vì Order Service gửi một yêu cầu cho các services khác phải làm gì, với EDA, Order Service chỉ đơn giản là phát đi một thông báo về một sự kiện vừa xảy ra trong hệ thống. Thông báo này được gọi là một Sự kiện (Event).

Ví dụ: Order Service sẽ phát đi sự kiện "OrderPlaced" (Đơn hàng đã được tạo).

Các thành phần chính

Kiến trúc EDA có các thành phần chính:

• Event Producer: Là bên tạo ra sự kiện (ví dụ trong bài toán trên thì Event Producer chính là Order Service).
• Event Consumer: Bên nhận và xử lí sự kiện (ví dụ: Payment Service).
• Event Bus/Broker:: Có vai trò giống như một bưu điện. Mọi sự kiện sẽ được gửi đến đây. Các Consumers sẽ cần (đăng ký) để lắng nghe những sự kiện cần quan tâm.

Workflow mới sẽ như sau:

1. Order Service phát sự kiện OrderPlaced lên Event Bus.
2. Payment Service và Inventory Service đã đăng ký lắng nghe sự kiện này. Chúng đồng thời nhận được sự kiện và bắt đầu xử lý.
3. Khi Payment Service xử lý xong, nó lại phát một sự kiện mới: PaymentSucceeded.
4. Shipping Service và Notification Service đang lắng nghe sự kiện PaymentSucceeded, chúng nhận được tin và bắt đầu công việc của mình.

Đoạn code tương ứng

import java.time.LocalDateTime;
import java.util.Map;
import java.util.UUID; public class OrderService { private EventBus eventBus; public OrderService(EventBus eventBus) { this.eventBus = eventBus; } public String placeOrder(OrderData orderData) { String orderId = createOrderRecord(orderData); // Publish một sự kiện duy nhất lên Event Bus Map<String, Object> eventPayload = Map.of( "order_id", orderId, "customer_id", orderData.getCustomerId(), "items", orderData.getItems(), "total", orderData.getTotal(), "timestamp", LocalDateTime.now() ); eventBus.publish("OrderPlaced", eventPayload); return orderId; } private String createOrderRecord(OrderData orderData) { // TODO: implement persistence logic return UUID.randomUUID().toString(); // Giả lập tạo ID đơn hàng }
}

EDA mang lại một số lợi ích sau:

• Hoàn toàn độc lập: Order Service không cần biết ai đang nghe nó. Nếu ngày mai có thêm 10 services mới cần dữ liệu đơn hàng, chúng chỉ việc đăng ký vào Event Bus mà không cần thay đổi dù chỉ một dòng code của Order Service.
• Siêu linh hoạt và dễ mở rộng: Việc thêm một tính năng mới chỉ đơn giản là tạo ra một Consumer mới và cho nó lắng nghe sự kiện phù hợp.

Lời kết

Hành trình từ kiến trúc đồng bộ, qua hàng đợi bất đồng bộ, và cuối cùng đến kiến trúc hướng sự kiện cho thấy một sự tiến hóa tất yếu trong thiết kế phần mềm. EDA không chỉ là một công nghệ, nó là một cách tư duy giúp chúng ta xây dựng những hệ thống phức tạp một cách linh hoạt, bền bỉ và sẵn sàng cho tương lai.

Hy vọng bài viết này đã cho bạn một cái nhìn tổng quan về sức mạnh của Event-Driven Architecture.