Event-Driven Architecture

01 EDA là gì?

Đa số ứng dụng theo mô hình request: một orchestrator (UI/API) đồng bộ & tất định điều hướng request tới các bộ xử lý. EDA lật ngược: các thành phần phản ứng với sự kiện một cách bất đồng bộ, tách rời nhau.

02 Broker topology

Không có mediator trung tâm. Luồng tin nhắn lan theo kiểu chuỗi/phát sóng qua một message broker nhẹ (RabbitMQ, ActiveMQ…), thường dùng topic + pub-sub. Bốn thành phần: sự kiện khởi đầu, event broker, event processor, sự kiện xử lý (processing event).

flowchart LR
  IE["Initiating event
(PlaceOrder)"]:::ie --> BR(("Broker
topic")):::br
  BR --> P1["OrderPlacement"]:::ep
  P1 -->|"order-created"| BR2(("Broker")):::br
  BR2 --> P2["Payment"]:::ep
  BR2 --> P3["Inventory"]:::ep
  BR2 --> P4["Notification"]:::ep
  classDef ie fill:#f3e6c8,stroke:#9a6712,color:#1c1a14;
  classDef br fill:#14233b,stroke:#14233b,color:#f3ede0;
  classDef ep fill:#e7ddf2,stroke:#6a4ca8,color:#1c1a14;
            

03 Mediator topology

Một event mediator trung tâm quản lý & điều khiển workflow. Năm thành phần: sự kiện khởi đầu, event queue, event mediator, event channels, event processors. Mediator biết các bước, sinh ra các lệnh (command) gửi point-to-point; processor làm xong báo lại mediator (không quảng cáo ra ngoài).

flowchart LR
  IE["Initiating event"]:::ie --> Q["Event queue"]:::q --> M{{"Event Mediator"}}:::med
  M -->|"place-order (command)"| C1["OrderPlacement"]:::ep
  M -->|"apply-payment"| C2["Payment"]:::ep
  M -->|"update-inventory"| C3["Inventory"]:::ep
  C1 -. ack .-> M
  C2 -. ack .-> M
  C3 -. ack .-> M
  classDef ie fill:#f3e6c8,stroke:#9a6712,color:#1c1a14;
  classDef q fill:#e2edf3,stroke:#2f6d93,color:#1c1a14;
  classDef med fill:#14233b,stroke:#14233b,color:#f3ede0;
  classDef ep fill:#e7ddf2,stroke:#6a4ca8,color:#1c1a14;
            

04 Bất đồng bộ, lỗi & chống mất dữ liệu

Hai kiểu giao tiếp bất đồng bộ

Workflow event pattern (xử lý lỗi)

Khi consumer gặp lỗi, nó uỷ quyền ngay cho một workflow processor (error handler) rồi đọc tiếp tin nhắn sau — không để cả hàng đợi nghẽn vì một tin lỗi. Workflow processor cố sửa & gửi lại queue gốc; không sửa được thì đẩy lên "dashboard" cho người xử lý tay.

Ba kỹ thuật chống mất tin nhắn

05 Rating & hệ RAG

EDA mạnh tuyệt đối ở hiệu năng, mở rộng, chịu lỗi, tiến hoá — nhưng rất phức tạp & khó test.

Ingest RAG theo Broker

RAG  Nạp tài liệu rất hợp Broker: upload phát một sự kiện, các processor lần lượt phản ứng — tách rời, dễ thêm bước mới (vd "trích entity") mà không sửa cái cũ.

flowchart LR
  UP["document-uploaded"]:::ie --> B(("Broker")):::br
  B --> CH["Chunker"]:::ep
  CH -->|"doc-chunked"| B2(("Broker")):::br
  B2 --> EM["Embedder"]:::ep
  B2 --> EX["Trích entity (thêm sau)"]:::ep
  EM -->|"chunk-embedded"| B3(("Broker")):::br --> IX["Indexer → Vector Store"]:::ep
  classDef ie fill:#f3e6c8,stroke:#9a6712,color:#1c1a14;
  classDef br fill:#14233b,stroke:#14233b,color:#f3ede0;
  classDef ep fill:#e7ddf2,stroke:#6a4ca8,color:#1c1a14;
            

// Đẩy sự kiện rồi trả lời NGAY — không bắt người dùng chờ embed
$bus->publish('document-uploaded', ['doc_id' => $id]);
return response()->json(['status' => 'accepted'], 202);  // 25ms, không phải 3000ms

06 Ghi nhớ nhanh