Eventarc Advanced — Bus, Enrollment & Pipeline

Eventarc Advanced là một product riêng biệt, không phải "Eventarc Standard với thêm features". Nó giải quyết một bài toán khác: governance trong event-driven architecture ở quy mô nhiều team. Để hiểu tại sao Advanced tồn tại, cần hiểu rõ giới hạn mà Standard không vượt qua được.

Governance Gap trong Eventarc Standard

Eventarc Standard được thiết kế cho use case đơn giản và rõ ràng: "khi có event X từ source Y, gọi destination Z". Với một team, một vài services, điều này hoàn toàn đủ.

Nhưng khi một hệ thống có nhiều team tự trị, mỗi team publish events và consume events của nhau, Standard bộc lộ những giới hạn cốt lõi:

1. Không có centralized policy enforcement

Bất kỳ service nào cũng có thể publish event với bất kỳ source attribute nào. Không có cơ chế nào ngăn service A giả mạo source của service B. Trong Pub/Sub hay Standard, event data là opaque blob — routing infrastructure không "đọc" nội dung.

2. Không có content-based access control

Standard filter chỉ hoạt động trên event type và một số metadata attributes cố định. Không thể viết rule như "chỉ deliver events có data_sensitivity: general, block events có data_sensitivity: restricted khỏi reaching service X".

3. Không có payload transformation

Events phải được delivered nguyên vẹn đến destination. Nếu Finance team publish events với schema riêng, Logistics team phải viết code để parse schema đó. Không có lớp transformation nào nằm giữa.

4. Fan-out không có governance

Để fan-out một event đến nhiều consumer, cần tạo nhiều trigger riêng lẻ. Không có cách nào audit "ai đang subscribe vào event type này" từ một góc nhìn tập trung.

Eventarc Advanced giải quyết tất cả những điểm này bằng cách giới thiệu một mô hình kiến trúc mới: bus + enrollment + pipeline.

Mô hình kiến trúc Advanced

                      ┌─────────────────────────────────┐
                      │           EVENT BUS              │
                      │    (Governance layer - Envoy)    │
                      │                                  │
  Publishers ─────────│──> Source integrity enforcement  │
  (any service)       │──> Content-based access control  │
                      │──> VPC Service Controls          │
                      └────────────┬────────────────────┘
                                   │
                    ┌──────────────┼──────────────┐
                    │              │              │
              Enrollment A   Enrollment B   Enrollment C
              (CEL filter)   (CEL filter)   (CEL filter)
                    │              │              │
               Pipeline A    Pipeline B    Pipeline C
               (transform)   (transform)   (transform)
                    │              │              │
              Destination A  Destination B  Destination C

Ba primitive mới này phân tách trách nhiệm quản trị khỏi trách nhiệm delivery, giống cách Kubernetes tách control plane khỏi data plane.

Bus: Governance Layer

Bus là router trung tâm nhận tất cả events từ publishers. Về kỹ thuật, bus được xây trên Envoy — cùng proxy đứng sau Cloud Load Balancing và Cloud Service Mesh. Điều này không phải ngẫu nhiên: Envoy được chọn vì nó có khả năng content inspection và policy enforcement.

Bus không phải là một queue hay buffer — nó là point-of-enforcement: một nơi duy nhất mà platform administrator có thể viết policies áp dụng cho tất cả events trước khi chúng được route đến bất kỳ consumer nào.

Source integrity enforcement

Một vấn đề cơ bản trong messaging: bất kỳ publisher nào cũng có thể claim bất kỳ source nào. Nếu system A publish event với source: //commerce/payments, làm sao bạn biết nó thực sự từ payments service chứ không phải một service khác giả mạo?

Bus trong Eventarc Advanced cho phép viết policy như:

Policy: principal sa-commerce@project.iam.gserviceaccount.com
        chỉ được publish events với source.startsWith("//commerce/")

Nếu Intelligence AI Agent thử publish event claiming origin //commerce/payments, bus sẽ reject với 403. Không cần consumer tự validate — bus enforce ở tầng infrastructure.

Content-based access control (FGAC)

Bus inspect CloudEvents attributes (không phải payload data) để enforce fine-grained access control. Ví dụ:

Policy: Events với attribute data_sensitivity = "restricted"
        chỉ được route đến Finance service
        
Policy: Events thiếu attribute data_sensitivity
        bị reject — tất cả events phải được classified

Đây là capability không thể có trong Standard mode vì Standard routing engine không "đọc" event content.

Fully regional service

Eventarc Advanced là fully regional: bus, enrollments, và pipelines đều phải cùng một region. Events không cross region boundary trong Advanced mode. Đây là design decision có chủ ý để đảm bảo data residency và giảm latency.

Giới hạn quota:

• 1 bus per project per region
• 100 pipelines per project per region

Enrollment: CEL-Based Subscription

Enrollment là cơ chế "đăng ký" nhận events từ bus. Nó bao gồm hai phần:

1. CEL filter expression: xác định events nào sẽ được route
2. Pipeline pointer: chỉ định pipeline nào xử lý matched events

CEL expressions trong enrollment

Common Expression Language (CEL) là language mà Kubernetes cũng dùng trong ValidatingAdmissionPolicy. Trong Eventarc Advanced, CEL được dùng để filter trên CloudEvents attributes:

# Chỉ nhận events liên quan đến order tạo mới và có giá trị cao
message.type == "com.retail.order.created" && double(message.data.amount) > 5000.0

# Filter events của Finance team, exclude nội bộ
message.type.startsWith("com.finance.") && message.source != "//finance/internal-audit"

# Chỉ nhận events không chứa dữ liệu nhạy cảm
message.data_sensitivity == "general"

Khác với Eventarc Standard filter (chỉ exact match hoặc prefix match trên predefined attributes), CEL cho phép logic phức tạp kết hợp nhiều điều kiện.

Enrollment và pipeline là separate concerns

Một enrollment không chứa delivery logic — nó chỉ filter và chỉ định pipeline. Pipeline mới là nơi chứa delivery configuration. Sự tách biệt này có lý do:

• Enrollment thuộc về platform team: ai được nhận event nào — đây là governance decision
• Pipeline thuộc về team owner: deliver thế nào, transform thế nào — đây là integration decision

Platform team có thể cập nhật filter trong enrollment mà không cần touch pipeline. Team owner có thể cập nhật transformation trong pipeline mà không cần touch enrollment policy.

Pipeline: Delivery và Transformation

Pipeline là intermediary giữa bus và destination. Nó có ba vai trò:

1. Delivery: gửi event đến destination, handle retry
2. Transformation: biến đổi event content trước khi deliver
3. Format conversion: chuyển đổi giữa JSON, Protobuf, v.v.

Delivery configuration

Pipeline định nghĩa retry policy riêng, tách biệt với Pub/Sub-inherited policy của Standard:

• Default: exponential backoff, initial delay 1 giây, gấp đôi đến maximum 60 giây, 5 attempts
• Configurable: linear hoặc exponential backoff, max attempts

Lưu ý: Eventarc Advanced không hỗ trợ dead letter topic (tính đến thời điểm viết bài này). Nếu event không được deliver sau hết số lần retry, nó bị drop. Đây là một điểm cần lưu ý khi thiết kế.

CEL-based transformation

Transformation trong pipeline dùng CEL để biến đổi CloudEvents message trước khi deliver:

// Reshape data payload cho downstream service
{
  "order_id": message.data.order_number,
  "insured_value": message.data.total_amount * 1.1,
  "currency_code": message.data.currency.upperAscii(),
  "source_region": message.source.extract("//[a-z]+/([a-z-]+)/.*", 1)
}

Đây là in-flight transformation — source không biết, destination nhận data đã được shaped. Không cần viết adapter service. Không cần thêm hop trong data path.

Format conversion

Pipeline có thể convert format:

• JSON → Protobuf
• Protobuf → JSON

Ví dụ: Finance team publish JSON events. Logistics warehouse robots chỉ hiểu Protobuf. Pipeline tự động convert trong quá trình delivery, không cần cả hai phía thay đổi code.

HTTP Message Destination Binding (MDB)

MDB là feature cho phép pipeline construct chính xác HTTP request cần gửi đến destination, bao gồm cả headers và body. Đặc biệt hữu ích khi target là third-party API hay legacy service không hiểu CloudEvents format:

{
  "headers": {
    "X-API-Key": "${env.LEGACY_API_KEY}",
    "Content-Type": "application/json",
    "X-Correlation-Id": "${message.id}"
  },
  "body": {
    "transaction_id": "${message.data.order_id}",
    "amount": "${message.data.total_amount}",
    "currency": "${message.data.currency}"
  }
}

MDB cũng hỗ trợ Agent2Agent (A2A) Protocol và Model Context Protocol (MCP) — hai protocol đang nổi lên trong AI agent orchestration. Đây là một trong những lý do Eventarc Advanced được positioning như event fabric cho AI workloads.

Supported destinations trong Advanced

Eventarc Advanced hỗ trợ 200+ Google Cloud services như destination thông qua HTTP, bao gồm:

• Cloud Run
• Cloud Functions
• Pub/Sub topics (re-publish để fan-out)
• Workflows
• Custom HTTP endpoints (internal VPC hoặc external)

Không hỗ trợ GKE destination directly (đây là limitation so với Standard).

Delivery semantics của Advanced

Giống Standard, Advanced deliver at-least-once. Không có ordering guarantee. Duplicate events có thể xảy ra, consumer phải idempotent.

Tuy nhiên, cơ chế underlying khác: Advanced không dùng Pub/Sub subscription làm transport (không có managed Pub/Sub topic ẩn). Thay vào đó, bus nhận events qua API, và pipeline deliver trực tiếp.

Retention duration: 24 giờ — event không delivered trong 24h bị drop.

Standard vs Advanced: Khi nào chọn gì

Tiêu chí	Eventarc Standard	Eventarc Advanced
Độ phức tạp	Thấp — trigger, source, destination	Cao hơn — bus, enrollment, pipeline
Governance	Không có	Centralized policy, FGAC
Filter power	Event type + fixed attributes	CEL expressions trên mọi attribute
Fan-out	Multiple triggers riêng biệt	Nhiều enrollments trên một bus
Payload transformation	Không có	CEL transformation
Format conversion	Không có	JSON ↔ Protobuf
Dead letter	Qua Pub/Sub subscription	Chưa hỗ trợ
Quota	500 triggers/project/region	1 bus, 100 pipelines/project/region
Event size	512 KB	1 MB
GA	Có	GA từ tháng 8/2025

Chọn Standard khi:

• Use case đơn giản: một source → một destination
• Không cần transformation hay content-based filtering
• Team nhỏ, ít event types

Chọn Advanced khi:

• Nhiều team, cần centralized governance
• Cần content-based access control (FGAC)
• Cần payload transformation hay format conversion
• Fan-out phức tạp với nhiều consumers
• Tích hợp với third-party APIs hay AI agents
• Cần enforce data classification policy

Một ví dụ minh họa: Multi-team event mesh

Để thấy Advanced giải quyết vấn đề gì trong practice, xem xét scenario: một e-commerce platform với 4 team tự trị.

Setup:

Commerce team  ──publish──►
Finance team   ──publish──►  [EVENT BUS]  ──route──► Logistics pipeline
Logistics team ──publish──►               ──route──► Finance pipeline
Intelligence AI──publish──►               ──route──► Analytics pipeline

Bus policies:

Policy 1: sa-commerce@project.iam.gserviceaccount.com
          → chỉ publish với source.startsWith("//commerce/")

Policy 2: Tất cả events phải có attribute data_sensitivity
          → reject nếu thiếu

Policy 3: Events có data_sensitivity = "restricted"
          → chỉ route đến Finance enrollment

Finance enrollment:

message.type.startsWith("com.commerce.payment.") &&
message.source.startsWith("//commerce/")

Logistics pipeline transformation:

// Finance publish JSON, Logistics cần Protobuf
// Pipeline tự động convert format

// Và reshape data
{
  "shipment_id": message.data.order_id,
  "delivery_address": message.data.shipping_address,
  "priority": double(message.data.total_amount) > 1000.0 ? "express" : "standard"
}

Trong setup này, mỗi team tự trị quản lý pipeline của mình (delivery logic, transformation) nhưng không thể bypass governance policies của bus. Platform team kiểm soát enrollment (ai được nhận gì) mà không cần touch code của từng team.

References

• Eventarc Advanced overview
• Getting to know Eventarc Advanced
• Eventarc Advanced orchestrates complex microservices
• Create a bus to route messages
• Create an enrollment to receive events
• Common Expression Language spec