Event-Driven Architecture (EDA) là gì?

Phần 1: EDA thực chất là gì? (Tư duy "Thông báo" thay vì "Yêu cầu")

Trong kiến trúc truyền thống (Request-Response), hệ thống hoạt động theo kiểu Mệnh lệnh:

Service A: "Này Service B, hãy tạo hóa đơn cho đơn hàng #123 này đi, tôi đứng đây đợi ông làm xong mới chạy tiếp."

Trong EDA, mọi thứ xoay quanh các Sự kiện (Events). Một sự kiện là một lời khẳng định về một việc đã xảy ra trong quá khứ.

Service A: "Tôi vừa hoàn thành thanh toán cho đơn hàng #123. Tôi ghi thông tin vào đây, ai cần thì tự lấy mà làm nhé!" (Sau đó Service A đi làm việc khác ngay lập tức).

Phần 2: "Bộ khung" của một hệ thống Event-Driven

Một hệ thống EDA chuẩn chỉ thường gồm 4 thành phần chính:

Event Producers (Người phát tin): Là nơi phát sinh sự kiện (ví dụ: User nhấn nút "Mua hàng").
Event (Sự kiện): Là dữ liệu về những gì đã xảy ra (ví dụ: OrderPlaced, PaymentSuccess).
Event Bus/Broker (Kênh truyền dẫn): "Trạm trung chuyển" như Kafka, RabbitMQ hoặc AWS EventBridge. Đây là nơi lưu trữ và điều phối các sự kiện.
Event Consumers (Người nhận tin): Các service đăng ký lắng nghe sự kiện để thực hiện logic nghiệp vụ tương ứng.

Phần 3: So sánh Sync (Request-Response) vs Async (EDA)

Để dễ hình dung khi nào nên dùng loại nào, hãy nhìn vào bảng so sánh này:

Đặc điểm	Request-Response (Đồng bộ)	Event-Driven (Bất đồng bộ)
Sự phụ thuộc	Chặt chẽ (Tight Coupling)	Lỏng lẻo (Loose Coupling)
Tốc độ phản hồi	Chậm hơn (Đợi kết quả từ bên nhận)	Cực nhanh (Gửi xong là xong)
Khả năng chịu lỗi	Một ông sập, cả chuỗi sập	Một ông sập, data vẫn nằm ở Broker
Độ phức tạp	Thấp, dễ debug	Cao, khó theo dõi luồng (Traceability)
Sử dụng khi	Cần kết quả ngay (VD: Xem số dư)	Xử lý hậu kỳ (VD: Gửi mail, thống kê)

Phần 4: Các Pattern "thượng thừa" trong EDA

Khi đã chơi hệ EDA, cần biết 2 khái niệm "đỉnh cao" này:

Event Sourcing: Thay vì chỉ lưu trạng thái hiện tại của User (ví dụ: balance = 100), bạn lưu tất cả các sự kiện đã dẫn đến trạng thái đó (+50, -20, +70). Điều này giúp bạn có thể "quay ngược thời gian" để điều tra bất kỳ lỗi nào.
CQRS (Command Query Responsibility Segregation): Tách biệt hoàn toàn việc Ghi dữ liệu và Đọc dữ liệu. Việc Ghi sẽ sinh ra Event, và một service khác sẽ nghe Event đó để cập nhật vào một database chuyên dụng cho việc Đọc (như Elasticsearch).

Phần 5: "Mặt tối" của EDA - Không có gì là miễn phí!

Dù EDA rất mạnh mẽ, nhưng nó cũng mang lại những "cơn đau đầu" cho Backend Engineer:

Tính nhất quán cuối cùng (Eventual Consistency): Dữ liệu không được cập nhật ngay lập tức ở mọi nơi. User vừa đổi tên, nhưng ở trang Thống kê có thể 2 giây sau mới thấy tên mới.
Xử lý trùng lặp (Idempotency): Một event có thể bị gửi 2 lần do lỗi mạng. Bạn phải code sao cho nếu nhận 2 lần cùng 1 event, kết quả vẫn không đổi.
Khó Debug: Việc request "bay nhảy" lung tung qua các service khiến việc tìm ra lỗi ở đâu trở nên gian nan hơn nhiều so với việc đọc Log của một khối Monolith.

Lời kết

EDA không phải là liều thuốc tiên cho mọi bài toán, nhưng nó là chìa khóa để xây dựng những hệ thống có thể mở rộng (Scale) không giới hạn. Tại Hasaki, khi lượng đơn hàng bùng nổ vào các dịp Sale, EDA sẽ giúp hệ thống của Hiếu không bị nghẽn cổ chai và mang lại trải nghiệm mượt mà nhất cho khách hàng.