Wavi Books · System Design, Backend & Microservices

Event-Driven Architecture là gì? Kiến trúc hướng sự kiện thực chiến

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Event-Driven Architecture là gì, event, producer, consumer, broker, eventual consistency và cách áp dụng kiến trúc hướng sự kiện.

## Event-Driven Architecture là gì

## Câu trả lời ngắn trước khi đi vào kiến trúc

Event-Driven Architecture là gì, event, producer, consumer, broker, eventual consistency và cách áp dụng kiến trúc hướng sự kiện. Hãy bắt đầu từ yêu cầu, điểm hỏng và hậu quả nghiệp vụ rồi mới chọn thành phần kỹ thuật.

Một hệ thống có thể chạy rất ổn trong buổi demo nhưng bắt đầu lộ vấn đề khi lưu lượng tăng, mạng chập chờn hoặc một dịch vụ phía sau phản hồi chậm. Lúc đó, câu hỏi đáng giá không phải là thêm công nghệ nào cho sơ đồ đẹp hơn, mà là điểm hỏng thật sự nằm ở đâu và người dùng chịu hậu quả gì.

Kiến trúc hướng sự kiện hấp dẫn vì các dịch vụ có vẻ độc lập hơn. Đổi lại, bạn phải học cách sống với độ trễ, sự kiện đến lặp và những lỗi không còn nằm gọn trong một request.

Event-Driven Architecture (EDA) là phong cách kiến trúc trong đó thành phần phát sự kiện khi trạng thái thay đổi và thành phần khác phản ứng bất đồng bộ. Sự kiện nên mô tả một điều đã xảy ra trong nghiệp vụ.

EDA giúp giảm kết nối trực tiếp và mở rộng xử lý, nhưng làm tăng độ khó quan sát, kiểm thử và nhất quán dữ liệu. Nó phù hợp khi lợi ích bất đồng bộ vượt chi phí vận hành.

## Những khái niệm cốt lõi cần nắm

## Sự kiện kể lại điều đã xảy ra

Thay vì dịch vụ A ra lệnh trực tiếp cho dịch vụ B, A phát ra một sự kiện như Đơn hàng đã tạo. Các hệ thống quan tâm tự lắng nghe và phản ứng. Điều này giảm phụ thuộc trực tiếp nhưng đòi hỏi hợp đồng sự kiện rõ ràng.

## Chuyện gì xảy ra khi đem vào dự án thật?

Trong luồng đặt hàng, thanh toán thành công có thể kích hoạt xuất kho, gửi email và cập nhật điểm thưởng. Nếu một consumer thất bại, bạn cần biết cách thử lại mà không trừ kho hoặc cộng điểm hai lần.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Hãy thiết kế idempotency, quan sát luồng và nơi lưu dấu vết ngay từ đầu. Event-driven phù hợp khi lợi ích tách rời thực sự lớn hơn chi phí vận hành phân tán.

- Producer phát sự kiện mà không cần biết mọi consumer.

- Broker lưu chuyển sự kiện.

- Consumer xử lý và cần idempotent.

- Eventual consistency chấp nhận độ trễ đồng bộ.

## Lộ trình thực hành từng bước

- Bước 1: Xác định domain event có ý nghĩa nghiệp vụ.

- Bước 2: Thiết kế schema và chính sách tương thích.

- Bước 3: Thêm retry, dead-letter, tracing và cơ chế bù.

## Những sai lầm thường gặp

- Dùng event như lời gọi RPC trá hình.

- Không quản lý thứ tự và trùng lặp.

- Thiếu correlation ID để truy vết.

## Góc nhìn dành cho người học và developer Việt Nam

Doanh nghiệp Việt Nam nên áp dụng EDA từng phần ở luồng đơn hàng, thanh toán hoặc thông báo, thay vì chuyển toàn bộ hệ thống sang sự kiện trong một lần.

## Nên học tiếp như thế nào?

## Bài tập thiết kế một luồng sự kiện

Mô tả luồng từ lúc đơn hàng được tạo đến khi khách nhận thông báo. Đặt tên sự kiện ở thì quá khứ, xác định producer, consumer và dữ liệu tối thiểu. Sau đó giả lập ba tình huống: sự kiện đến hai lần, consumer tạm dừng và schema có thêm trường. Cách bạn xử lý ba tình huống này sẽ cho thấy kiến trúc đã sẵn sàng cho đời thực hay mới đẹp trên sơ đồ.

## Ví dụ xuyên suốt để nối kiến thức

Khi thanh toán thành công, kho cần giữ hàng, hệ thống điểm thưởng cần cộng điểm và dịch vụ email cần gửi xác nhận. Phát sự kiện giúp ba phần phản ứng độc lập. Nhưng nếu sự kiện đến hai lần, cả ba consumer phải tránh tạo tác dụng phụ lặp.

## Khung triển khai từ thử nghiệm đến thực tế

Event-driven phù hợp khi nhiều hệ thống cần phản ứng độc lập, xử lý bất đồng bộ hoặc cần lưu dấu diễn biến. Request đồng bộ vẫn tốt hơn khi người dùng cần kết quả ngay và chuỗi xử lý ngắn, dễ kiểm soát.

### Bốn bước nên đi theo thứ tự

- Đặt tên sự kiện là sự thật nghiệp vụ đã xảy ra.

- Xác định schema, chủ sở hữu và khóa nhận diện duy nhất.

- Thiết kế consumer idempotent, retry có giới hạn và dead-letter queue.

- Theo dõi correlation ID xuyên suốt để điều tra một giao dịch.

## Trade-off cần nhìn thẳng

Tách rời làm team linh hoạt hơn nhưng mất tính nhất quán tức thời và stack trace liền mạch. Schema thay đổi, thứ tự sự kiện và dữ liệu đến muộn trở thành bài toán phải chủ động xử lý.

## Đánh giá bằng kết quả thay vì cảm giác

Theo dõi consumer lag, tỷ lệ retry, số sự kiện vào dead-letter queue và thời gian hoàn thành nghiệp vụ đầu cuối. Chỉ nhìn broker khỏe chưa đủ để biết người dùng có nhận kết quả hay không.

## Giá trị đối với năng lực nghề nghiệp

Hiểu sự kiện giúp backend developer thiết kế workflow phân tán thực tế, thay vì chỉ biết ghép queue vào sơ đồ kiến trúc.

## Câu hỏi tự kiểm tra trước khi chuyển chủ đề

Bạn có thể giải thích Event-Driven Architecture là gì bằng ngôn ngữ của mình, nêu một trường hợp nên dùng, một trường hợp không nên dùng và chỉ ra cách đo kết quả hay chưa? Nếu chưa, hãy quay lại ví dụ nhỏ trong bài, thay đổi một ràng buộc rồi quan sát điều gì buộc giải pháp phải thay đổi. Đây là cách biến kiến thức đọc được thành khả năng ra quyết định.

## Góc nhìn dành cho developer Việt Nam

Với backend developer và kỹ sư phần mềm tại Việt Nam, kiến thức này đặc biệt hữu ích khi làm sản phẩm có thanh toán, đơn hàng, dữ liệu khách hàng hoặc chuẩn bị phỏng vấn System Design. Nhà tuyển dụng thường quan tâm cách bạn giải thích giả định và đánh đổi hơn là số lượng công nghệ bạn nhớ tên.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Building Event-Driven Microservices, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/building-event-driven-microservices-adam-bellemare-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.