Event-Driven Multi-Agent Orchestration 2026 - Kiến trúc Kafka, Redis Streams, Temporal và ClickHouse cho hệ thống AI Agent Production

Posted on: 4/14/2026 2:10:17 PM

Năm 2025 là thời điểm các đội ngũ AI nhận ra một sự thật phũ phàng: orchestrator trung tâm không phải là đích đến cuối cùng của multi-agent. Khi số lượng agent vượt qua con số 10, khi mỗi bước có thể kéo dài hàng chục giây vì LLM call, khi một agent có thể cần retry 5 lần trước khi thành công — một orchestrator đồng bộ theo kiểu "gọi hàm truyền thống" nhanh chóng trở thành điểm nghẽn, điểm lỗi đơn, và là nguyên nhân khiến hoá đơn cloud tăng theo cấp số nhân. Bài viết này đi sâu vào kiến trúc event-driven multi-agent 2026: cách phối hợp hàng trăm agent bằng sự kiện thay vì lời gọi trực tiếp, dùng Kafka và Redis Streams làm message backbone, Temporal cho workflow bền vững, và ClickHouse để biến mọi event thành dữ liệu phân tích được.

1. Vì sao orchestration đồng bộ sụp đổ ở quy mô multi-agent

Hầu hết các hệ multi-agent hiện nay bắt đầu bằng một mô hình rất đơn giản: một orchestrator trung tâm gọi lần lượt planner → researcher → writer → critic → finalizer. Cách này dễ hiểu, dễ debug, và hoạt động tốt khi còn ở prototype. Nhưng khi đưa lên production, bốn vấn đề xuất hiện cùng lúc:

• Coupling thời gian (temporal coupling): Agent A phải đợi agent B hoàn thành mới chạy được. Nếu B gọi LLM tốn 30 giây, A bị block 30 giây dù không cần gì từ B.
• Tight coupling giao diện: Thêm một agent mới (ví dụ fact-checker) nghĩa là phải sửa code orchestrator. Mọi thay đổi đều lan ra trung tâm.
• Điểm lỗi đơn (SPOF): Orchestrator crash giữa chừng, toàn bộ workflow mất trạng thái. Không retry, không resume, không audit.
• Không scale theo workload: Một request nặng có 50 LLM call, một request nhẹ chỉ 2 LLM call — nhưng đều chạy qua cùng một orchestrator process, khiến tài nguyên bị lãng phí hoặc thắt cổ chai.

2. Orchestration vs Choreography — Hai triết lý cơ bản

Trước khi đi vào kỹ thuật, cần làm rõ hai thuật ngữ hay bị nhầm lẫn. Chúng có nguồn gốc từ microservices, nhưng áp dụng nguyên vẹn cho multi-agent:

graph LR
    subgraph "Orchestration (Đạo diễn)"
        O[Orchestrator] --> A1[Agent A]
        O --> A2[Agent B]
        O --> A3[Agent C]
        A1 -.->|result| O
        A2 -.->|result| O
        A3 -.->|result| O
    end
    subgraph "Choreography (Vũ điệu)"
        EB[Event Bus]
        B1[Agent A] -->|publish| EB
        B2[Agent B] -->|publish| EB
        B3[Agent C] -->|publish| EB
        EB -->|subscribe| B1
        EB -->|subscribe| B2
        EB -->|subscribe| B3
    end
    style O fill:#e94560,stroke:#fff,color:#fff
    style EB fill:#0f3460,stroke:#fff,color:#fff

Orchestration là mô hình có một "đạo diễn" biết toàn bộ quy trình. Đạo diễn gọi từng agent theo thứ tự, thu kết quả, quyết định bước tiếp theo. Ưu điểm là dễ tracking, dễ debug, logic tập trung. Nhược điểm là SPOF, khó scale, và vi phạm nguyên tắc encapsulation — đạo diễn biết quá nhiều về nội tại của từng agent.

Choreography giống như một đoàn vũ công: không ai chỉ huy, mỗi vũ công phản ứng với tín hiệu (sự kiện) từ người khác theo quy tắc đã học trước. Ưu điểm là loose coupling, scale độc lập, resilient. Nhược điểm là khó nhìn toàn cảnh, dễ rơi vào trạng thái "cyclic dependency" nếu không thiết kế cẩn thận, và khó debug vì không có "nhật ký tập trung".

3. Kiến trúc tham khảo: Event-Driven Multi-Agent 2026

Dưới đây là một kiến trúc tham khảo đã được kiểm chứng trong nhiều hệ thống enterprise. Nó kết hợp Redis Streams (low-latency coordination), Kafka (durable event backbone), Temporal (durable workflow), ClickHouse (event store + analytics), và các agent chạy độc lập theo mô hình consumer group.

graph TB
    U[User Request] --> GW[API Gateway]
    GW --> T[Temporal Workflow
Saga orchestrator]
    T -->|publish intent| K[Kafka
agent.intents]
    K --> RA[Researcher Agent Pool]
    K --> WA[Writer Agent Pool]
    K --> CA[Critic Agent Pool]
    RA -->|result event| K2[Kafka
agent.results]
    WA -->|result event| K2
    CA -->|result event| K2
    K2 --> T
    RA -->|hot state| RS[Redis Streams
agent.coordination]
    WA -->|hot state| RS
    CA -->|hot state| RS
    K --> CH[ClickHouse
event archive]
    K2 --> CH
    RS --> CH
    CH --> DASH[Grafana / Langfuse
observability]
    style T fill:#e94560,stroke:#fff,color:#fff
    style K fill:#0f3460,stroke:#fff,color:#fff
    style K2 fill:#0f3460,stroke:#fff,color:#fff
    style RS fill:#4CAF50,stroke:#fff,color:#fff
    style CH fill:#2c3e50,stroke:#fff,color:#fff
    style DASH fill:#ff9800,stroke:#fff,color:#fff

Bảy thành phần chính trong kiến trúc này:

1. API Gateway — tiếp nhận request, ký session, định tuyến tới workflow engine.
2. Temporal — "bộ não" durable cho workflow dài (phút đến giờ). Nó không thực thi LLM call trực tiếp, mà phát intent event và chờ kết quả.
3. Kafka — event backbone bền vững cho các sự kiện quan trọng: intent, result, decision, audit. Partition theo session_id để giữ thứ tự trong cùng session.
4. Redis Streams — low-latency coordination cho những tín hiệu "nóng": heartbeat, progress update, tool call status. Không cần durability dài hạn.
5. Agent pool — các worker ngang hàng (stateless), subscribe vào Kafka consumer group, cạnh tranh xử lý message.
6. ClickHouse — event store cho mọi sự kiện sau khi chảy qua Kafka. Dùng cho analytics, replay, training data, và observability.
7. Dashboard layer — Grafana / Langfuse cho trace, cost, quality.

4. Redis Streams — low-latency coordination cho agent

Redis Streams là một data structure ít được biết đến nhưng cực kỳ mạnh cho multi-agent. Nó kết hợp đặc tính của append-only log (giống Kafka) với tốc độ trả lời sub-millisecond của Redis. Với hệ thống agent cần phản hồi ở mức 10ms, Redis Streams là lựa chọn tự nhiên cho những loại event dưới đây:

• Heartbeat: Mỗi agent publish một tick mỗi giây vào stream để báo "tôi còn sống". Supervisor tiêu thụ stream để phát hiện agent chết.
• Progress update: "Đang gọi LLM", "Đang chạy tool web_search", "Đã xong 3/7 bước" — những tín hiệu cần tốc độ, không cần bền vững.
• Claim token: Agent pool dùng XREADGROUP với consumer group để phân chia công việc theo kiểu at-least-once.
• Backpressure signal: Supervisor publish "PAUSE" vào stream khi hệ thống quá tải, mọi agent nghe thấy và dừng nhận message mới.

# Producer: agent phát heartbeat
import redis
r = redis.Redis(host='redis', port=6379)

def heartbeat(agent_id):
    r.xadd(
        'agent.heartbeat',
        {
            'agent_id': agent_id,
            'ts': int(time.time() * 1000),
            'status': 'alive',
            'queue_depth': get_local_queue_depth(),
        },
        maxlen=10000,       # giới hạn stream length
        approximate=True    # trim nhanh, cho phép sai số nhỏ
    )

# Consumer group: supervisor đọc heartbeat
r.xgroup_create('agent.heartbeat', 'supervisor', id='0', mkstream=True)

while True:
    msgs = r.xreadgroup(
        'supervisor', 'sup-01',
        {'agent.heartbeat': '>'},
        count=100, block=1000
    )
    for stream, entries in msgs:
        for entry_id, data in entries:
            detect_dead_agent(data)
            r.xack('agent.heartbeat', 'supervisor', entry_id)

5. Kafka — event backbone bền vững cho workflow dài

Redis Streams tốt cho tín hiệu nóng, nhưng không phù hợp làm hệ thống lưu trữ sự kiện nhiều ngày. Với những event quan trọng cần audit, replay, training — Kafka là lựa chọn mặc định của thế giới enterprise. Trong kiến trúc multi-agent, Kafka đóng năm vai trò:

1. Durable log: Sự kiện không mất khi Kafka broker restart hay agent crash.
2. Fan-out song song: Một "intent" có thể kích hoạt 5 agent pool khác nhau, mỗi pool là một consumer group đọc độc lập.
3. Replay: Khi phát hiện một regression, có thể replay toàn bộ sự kiện 7 ngày trước để debug hoặc tạo training dataset.
4. Decoupling deployment: Thay phiên bản agent mới không cần phối hợp với producer — chỉ cần rollout trên consumer group.
5. Schema evolution: Dùng Schema Registry (Confluent hoặc Apicurio) để đảm bảo agent cũ vẫn hiểu event mới.

5.1 Thiết kế topic cho agent event

Một lỗi thường gặp là tạo quá nhiều topic hoặc quá ít topic. Quy tắc đề xuất:

Dùng session_id làm partition key đảm bảo mọi event của cùng một session rơi vào cùng partition — nhờ đó consumer xử lý theo thứ tự mà không cần global locking.

6. Temporal — workflow bền vững cho saga multi-agent

Temporal (gốc từ Uber Cadence) là một trong những công nghệ "âm thầm" đang định hình lại cách xây dựng agent workflow. Thay vì viết code orchestrator bình thường, bạn viết hàm workflow — Temporal sẽ tự động chụp lại state máy vào durable storage, cho phép resume từ bất kỳ đâu dù process crash, machine die, hay mất mạng hàng giờ.

Ba lý do Temporal phù hợp với multi-agent:

• Durable execution: Workflow dài vài giờ hoặc vài ngày (chẳng hạn research agent thu thập dữ liệu) không mất state khi worker restart.
• Timers và retries first-class: workflow.sleep(hours=2) không tốn memory process, được Temporal schedule lại. Mọi activity tự động retry với backoff.
• Signals & queries: Workflow có thể nhận tín hiệu ngoài (user approval, human-in-the-loop) mà không cần polling — rất phù hợp với agent cần review.

from temporalio import workflow
from datetime import timedelta

@workflow.defn
class ResearchWorkflow:
    @workflow.run
    async def run(self, topic: str) -> dict:
        # Bước 1: plan
        plan = await workflow.execute_activity(
            publish_intent, f"plan:{topic}",
            start_to_close_timeout=timedelta(minutes=5),
            retry_policy=RetryPolicy(maximum_attempts=3),
        )
        # Bước 2: fan-out research
        results = await asyncio.gather(*[
            workflow.execute_activity(
                publish_intent, f"research:{q}",
                start_to_close_timeout=timedelta(minutes=10),
            ) for q in plan.queries
        ])
        # Bước 3: chờ human-in-the-loop nếu cần
        if plan.requires_approval:
            approval = await workflow.wait_condition(
                lambda: self._approved, timeout=timedelta(hours=24)
            )
        # Bước 4: tổng hợp
        return await workflow.execute_activity(
            publish_intent, f"synthesize:{results}",
            start_to_close_timeout=timedelta(minutes=15),
        )

    @workflow.signal
    def approve(self):
        self._approved = True

7. Saga Pattern — giao dịch phân tán cho multi-agent

Một workflow multi-agent có thể đụng tới năm, bảy dịch vụ ngoài: gửi email, ghi CRM, trừ quota LLM, tạo ticket Jira, thanh toán. Nếu một bước thất bại ở giữa, bạn không thể "rollback" theo kiểu ACID. Saga Pattern là giải pháp: mỗi bước có một compensating action, khi saga fail thì chạy các compensation theo thứ tự ngược lại.

sequenceDiagram
    participant W as Workflow
    participant A1 as Agent 1 (Research)
    participant A2 as Agent 2 (Write)
    participant A3 as Agent 3 (Send email)
    participant CRM as CRM
    W->>A1: intent:research
    A1-->>W: result:research
    W->>A2: intent:write
    A2-->>W: result:write
    W->>A3: intent:send_email
    A3--xW: FAIL
    Note over W: Saga compensation
    W->>CRM: delete draft
    W->>A2: revoke write credit
    W->>A1: archive research

Có hai kiểu saga thường gặp:

1. Orchestrated saga: Temporal workflow làm đạo diễn, biết thứ tự bước và compensation. Dễ đọc, dễ debug — được khuyên dùng cho multi-agent 80% trường hợp.
2. Choreographed saga: Mỗi agent phát event sau khi xong, agent tiếp theo tự động listen. Khi fail, agent phát "compensate" event. Ít tập trung hơn nhưng khó trace.

8. ClickHouse — event store và analytics cho toàn hệ thống

Kafka giữ được event trong vài ngày đến vài tuần, nhưng nó không phải là database để truy vấn. Khi muốn hỏi: "trong 30 ngày qua, agent nào gọi tool web_search nhiều nhất?", "tổng chi phí theo tenant như thế nào?", "những session nào vượt 60 giây?" — bạn cần một columnar store có thể quét hàng tỉ row trong vài giây. ClickHouse là lựa chọn tiêu chuẩn 2026 cho vai trò này.

Một bảng event ClickHouse tối ưu cho multi-agent:

CREATE TABLE agent_events (
    event_id       UUID,
    session_id     String,
    tenant_id      String,
    agent_id       LowCardinality(String),
    agent_type     LowCardinality(String),
    event_type     LowCardinality(String),  -- intent|result|tool_call|error
    ts             DateTime64(3, 'UTC'),
    duration_ms    UInt32,
    model          LowCardinality(String),
    input_tokens   UInt32,
    output_tokens  UInt32,
    cache_tokens   UInt32,
    cost_usd       Decimal(10, 6),
    status         LowCardinality(String),
    error_code     LowCardinality(String),
    payload        String CODEC(ZSTD(3)),
    trace_id       String,
    span_id        String,
    parent_span_id String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (tenant_id, ts, session_id)
TTL ts + INTERVAL 90 DAY DELETE;

Ba bí quyết khi thiết kế bảng này:

• LowCardinality: Dùng cho các cột có ít unique value (model, agent_type, status). Tăng tốc compress và query 5-10 lần.
• ORDER BY có tenant_id đầu tiên: Trong SaaS multi-tenant, mọi query đều filter theo tenant — đặt nó đầu trong primary key giúp Data Skipping Index hoạt động tốt nhất.
• PARTITION BY theo tháng: Cho phép TTL drop partition cực nhanh, không ảnh hưởng write path.

8.1 Pipeline ingest từ Kafka vào ClickHouse

Hai phương án phổ biến:

1. Kafka Engine (built-in): ClickHouse có storage engine Kafka + materialized view để pull message trực tiếp. Đơn giản nhưng kém linh hoạt, dễ mất message khi restart.
2. Clickhouse-kafka-connect hoặc Vector.dev: Một sidecar riêng làm nhiệm vụ consume Kafka, transform, batch insert qua HTTP/gRPC. Production-grade, monitoring dễ hơn, có back-off khi ClickHouse quá tải.

9. Backpressure, circuit breaker và dead-letter queue

Một hệ thống multi-agent event-driven nếu không có cơ chế kiểm soát dòng chảy sẽ tự hủy khi gặp traffic spike. Ba patterns bắt buộc:

9.1 Backpressure

Khi downstream chậm (ví dụ LLM API bị throttle), upstream phải giảm tốc. Trong Kafka, backpressure tự nhiên: consumer chỉ pull message khi sẵn sàng. Với Redis Streams, dùng XLEN để đo độ dài pending và reject message mới khi vượt ngưỡng. Với Temporal, dùng MaxConcurrentActivityExecutionSize trên worker option.

9.2 Circuit breaker

Khi một LLM provider lỗi liên tục, agent phải "ngắt cầu dao" để tránh flood retries. Thư viện pybreaker (Python) hoặc resilience4j (JVM) cho phép định nghĩa ngưỡng:

from pybreaker import CircuitBreaker

llm_breaker = CircuitBreaker(
    fail_max=5,          # 5 lần lỗi liên tiếp
    reset_timeout=30,    # nghỉ 30 giây
    exclude=[RateLimitError]  # không tính rate limit là "lỗi"
)

@llm_breaker
def call_claude(prompt):
    return anthropic.messages.create(...)

9.3 Dead-letter queue (DLQ)

Message xử lý thất bại quá N lần (thường 3-5 lần với exponential backoff) phải được chuyển sang một topic agent.deadletter.v1. DLQ có ba vai trò: (1) không chặn partition chính, (2) cho phép người vận hành kiểm tra root cause, (3) cho phép replay sau khi sửa lỗi. Một DLQ không được đọc định kỳ là DLQ vô nghĩa — hãy có dashboard và cảnh báo theo depth.

10. Observability đặc thù cho event-driven agent

Trace một request truyền qua 5 topic Kafka, 3 Redis Stream, 2 Temporal workflow, 20 LLM call — là cơn ác mộng nếu không chuẩn hóa từ đầu. OpenTelemetry GenAI Semantic Conventions cung cấp schema attribute chuẩn (xem bài viết về LLM Observability trước). Ngoài ra, cần thêm các rule riêng cho event-driven:

• Propagate trace context qua Kafka header: Khi producer publish, thêm traceparent vào Kafka record header. Consumer extract ra để tạo child span — trace không bị đứt qua topic.
• Log "event lineage": Mỗi event nên mang causation_id (event nào đã gây ra tôi) và correlation_id (id logic của business flow).
• Kappa vs Lambda architecture: Chọn Kappa (mọi thứ chảy qua Kafka rồi vào ClickHouse) để tránh lệch số liệu giữa realtime và batch.
• SLO theo event type: Mỗi event type có SLO riêng: latency p99 của intent→result khác với latency của audit→clickhouse.

11. Anti-patterns thường gặp

12. Roadmap triển khai 6 tháng

13. Kết luận — Event là hợp đồng, không phải log

Thay đổi tâm thế lớn nhất khi chuyển sang event-driven multi-agent là coi event như một hợp đồng, chứ không phải log gỡ lỗi. Một khi event đã publish, không thể rút lại; schema thay đổi phải tương thích ngược; payload phải đủ thông tin để một agent mới (chưa biết gì về producer) có thể xử lý. Tâm thế này khiến bạn thiết kế chậm hơn, nhưng hệ thống bền vững, dễ mở rộng, và có thể thay thế từng phần mà không phải viết lại orchestrator.

Năm 2026 sẽ là năm mà các kiến trúc agent trưởng thành — không còn "một LLM một prompt" mà là mạng lưới hàng chục agent chuyên dụng, hợp tác qua sự kiện, được Temporal điều phối bền vững, Kafka làm xương sống, Redis Streams cho phản xạ nhanh, ClickHouse cho trí nhớ phân tích. Nếu bạn đang bắt đầu xây dựng một hệ multi-agent, hãy chọn đúng kiến trúc ngay từ đầu — chi phí refactor về sau cao gấp nhiều lần so với chi phí học và cài đặt đúng cách.

14. Nguồn tham khảo

• Apache Kafka Documentation — Apache Software Foundation
• Redis Streams — Redis Documentation
• Temporal Workflows — Durable Execution Engine
• ClickHouse Kafka Integration
• Saga Pattern — Microservices.io (Chris Richardson)
• OpenTelemetry GenAI Semantic Conventions
• What do you mean by "Event-Driven"? — Martin Fowler
• Event-Driven Architecture Guide — Confluent
• Choreography Pattern — Microsoft Azure Architecture Center
• Building Effective Agents — Anthropic Research