Kiến trúc hướng sự kiện (Event-Driven) là gì? Cấu trúc và cách hoạt động như thế nào?

Question

IT Interview Practice · Accepted Answer

**Event-Driven Architecture (EDA) tổ chức công việc xoay quanh event: thông báo mô tả một sự việc đã xảy ra.** Ví dụ, sau khi đơn hàng được chấp nhận, các thành phần khác có thể phản ứng với `OrderPlaced` mà thành phần đơn hàng không phải gọi lần lượt từng bên.

Ý chính là tách việc ghi nhận một sự việc khỏi những công việc cần làm sau đó. Cách này có thể dùng trong một ứng dụng hoặc giữa nhiều service. Nó không bắt buộc microservices và không bảo đảm mọi việc được xử lý ngay lập tức. [AWS giải thích quan hệ producer–consumer này](https://aws.amazon.com/event-driven-architecture/).

## 1. Có những thành phần nào?

- **Producer:** ghi nhận hành động và phát event. Trong ví dụ này, thành phần đơn hàng thông báo một đơn đã được chấp nhận.
- **Event:** chứa sự việc và các thông tin nhận diện cần thiết, như mã event, mã đơn hàng và thời điểm xảy ra.
- **Consumer:** phản ứng với loại event mình hiểu. Consumer email gửi xác nhận; consumer báo cáo cập nhật số liệu bán hàng.
- **Kênh chuyển event:** đưa event đến nơi nhận. Trong cùng tiến trình, có thể dùng bộ điều phối event. Giữa các service, có thể dùng broker để nhận, lưu và phân phối thông báo theo cấu hình.

Sơ đồ sau dùng broker, với mỗi consumer đăng ký nhận một bản riêng:

```text
Customer -> Orders -> Orders database
               |
               | OrderPlaced(orderId=42, eventId=e1)
               v
             Broker
               |----------> Email
               |----------> Reporting
```

Email và Reporting đều cần nhận được event đó. Các worker cùng lấy việc từ một queue thường chia nhau xử lý thông báo; chỉ dùng cách này chưa bảo đảm cả hai chức năng đều nhận mọi event. Xem [mô hình Publisher–Subscriber](https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber).

## 2. Theo dõi một đơn hàng từ đầu vào đến kết quả

Giả sử khách đặt đơn hàng 42:

1. **Orders kiểm tra và lưu đơn.** Nó trả lại mã đơn đã được chấp nhận. Phản hồi này chưa có nghĩa email đã gửi xong.
2. **Orders đưa `OrderPlaced` vào luồng chuyển event.** Thông báo mô tả việc đã hoàn thành; nó khác với command yêu cầu một service cụ thể làm việc gì đó.
3. **Email nhận event** rồi gửi xác nhận. **Reporting nhận bản của mình** và đưa đơn 42 vào số liệu.
4. Khách thấy đơn được chấp nhận trước. Email và số liệu báo cáo có thể xuất hiện sau vì các công việc này chạy độc lập.

Nếu Email tạm thời ngừng hoạt động, cơ chế chuyển event có lưu bền vững có thể giữ thông báo rồi thử lại sau. Reporting vẫn có thể tiếp tục. Điều này phụ thuộc vào cấu hình lưu giữ, xác nhận đã xử lý và thử lại; chỉ gọi hệ thống là EDA chưa tạo ra các khả năng đó.

## 3. Khi có lỗi, cần xử lý những gì?

Không được để đơn đã lưu nhưng thông báo về đơn bị mất mà không ai biết. Một cách xử lý là **outbox**: lưu đơn và event đang chờ gửi trong cùng transaction của database, sau đó cho tiến trình nền chuyển event đi.

Thông báo có thể được giao lại. Consumer vì vậy cần **xử lý idempotent**, nghĩa là nhận lại cùng event không làm lặp tác động nghiệp vụ. Với email, chỉ ghi dấu đã gửi vẫn có khoảng hở nếu lỗi xảy ra quanh bước gọi dịch vụ gửi; nên dùng khả năng chống gửi trùng của nhà cung cấp nếu có, hoặc xử lý rõ giới hạn này.

Cũng cần quy định cách xử lý thông báo lỗi nhiều lần, giữ mã đơn để lần theo luồng và xác định event của cùng một đơn có cần xử lý đúng thứ tự hay không. Đây là các [điểm cần tính khi thiết kế EDA](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven).

## 4. Khi nào nên dùng EDA?

**Ưu điểm:** thêm một công việc phản ứng mới mà không thêm lời gọi trực tiếp vào Orders; tách tác vụ chậm ra chạy riêng; tiếp nhận đợt tải tăng tạm thời nếu kênh chuyển event có khả năng lưu chờ phù hợp.

**Hạn chế:** một luồng nghiệp vụ nằm rải ở nhiều thành phần. Bạn phải theo dõi độ trễ xử lý, thông báo bị lỗi và thay đổi cấu trúc event. Queue có thể trì hoãn tình trạng quá tải, nhưng không giải quyết được lượng việc tồn đọng tăng mãi.

Dùng EDA cho các phản ứng độc lập như thông báo, phân tích số liệu hoặc xử lý nền. Với thao tác nhỏ cần trả ngay một kết quả nhất quán, lời gọi trực tiếp hoặc transaction trong một ứng dụng thường đơn giản hơn. **EDA mô tả cách các thành phần phản ứng; Event Sourcing mô tả cách lưu dữ liệu chuẩn.** Có thể kết hợp hai cách này nhưng không bắt buộc đi cùng nhau.

1. Có những thành phần nào?

2. Theo dõi một đơn hàng từ đầu vào đến kết quả

3. Khi có lỗi, cần xử lý những gì?

4. Khi nào nên dùng EDA?

Câu hỏi liên quan