5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows

Event Routing and Service Orchestration: Eventarc & Cloud Workflows

Modern cloud-native architectures rely on two complementary architectural patterns to coordinate microservices: Event Routing (Choreography) and Service Orchestration. In Google Cloud, Eventarc provides the routing fabric that captures and normalizes events across Google Cloud services and delivers them to serverless consumers, while Cloud Workflows provides a stateful orchestration engine to coordinate multi-step, distributed business processes.

---

Eventarc Architecture & The CloudEvents Standard

Eventarc provides a unified, serverless event bus that transforms state changes across supported Google Cloud services into standardized CloudEvents v1.0 payloads. Instead of requiring applications to maintain bespoke event adapters, Eventarc standardizes event headers, delivery mechanisms, and filtering rules.

CloudEvents Format

Every event delivered by Eventarc adheres to the CNCF CloudEvents 1.0 specification:

• id: Unique identifier for the event instance.
• source: URI identifying the context in which the event occurred (e.g., //storage.googleapis.com/projects/_/buckets/my-bucket).
• specversion: Always 1.0.
• type: Specific event type (e.g., google.cloud.storage.object.v1.finalized, google.cloud.audit.log.v1.written).
• time: Timestamp of when the event occurred in RFC 3339 format.
• data: Service-specific JSON payload containing resource details.

Event Destinations

Eventarc delivers CloudEvents via HTTP POST requests to:

• Cloud Run services (fully managed container endpoints)
• Cloud Functions (2nd gen) (built on Cloud Run)
• Google Kubernetes Engine (GKE) services
• Cloud Workflows (initiating workflow executions)

Under the hood, Eventarc automatically manages an internal Cloud Pub/Sub transport topic and subscription to buffer and deliver events reliably.

---

Direct Triggers vs. Cloud Audit Log Triggers

Eventarc supports two distinct trigger mechanisms with different performance, scope, and configuration requirements.

The Audit Log Configuration Trap

Admin Activity, System Event and Policy Denied logs have their own default/always-written behavior; do not treat all audit logging as one switch. Data Access audit logs (which record data reads and writes) are disabled by default for many services; BigQuery is a notable default-enabled exception. Check the relevant service and operation rather than assuming every audit trigger needs the same logging category. Configure the needed data-operation logging explicitly and review its cost and access controls.

## Create a Direct Cloud Storage trigger targeting Cloud Run
gcloud eventarc triggers create gcs-direct-trigger \
    --location=us-central1 \
    --destination-run-service=document-processor \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=user-documents-bucket" \
    --service-account=eventarc-invoker@my-project.iam.gserviceaccount.com

---

Cloud Workflows: Serverless Service Orchestration

While Eventarc excels at routing individual events, complex business workflows require coordinating multiple microservices in a deterministic sequence, managing state transitions, and handling failures. Cloud Workflows is a fully managed, serverless orchestration engine that executes state machines defined in declarative YAML or JSON.

Core Workflows Constructs

• steps: An ordered list of steps executed sequentially unless altered by branching.
• call: Invoking an external HTTP endpoint (http.get, http.post) or a pre-built Google Cloud Connector (googleapis.bigquery.v2..., googleapis.pubsub.v1...).
• args: Arguments passed to the call, including URL, query parameters, JSON payload, and authentication.
• auth: Built-in credential management supporting type: OIDC or type: OAuth2 using dedicated service accounts.
• switch: Conditional branching logic based on variable evaluations.
• parallel: Executing multiple branches concurrently with optional concurrency throttling.
• try / except / retry: Granular exception handling and retry policies.

Declarative YAML Workflow Example

main:
  params: [event]
  steps:
    - init:
        assign:
          - orderId: ${event.data.orderId}
          - customerEmail: ${event.data.email}
          - amount: ${event.data.amount}
    
    - reserveInventory:
        try:
          call: http.post
          args:
            url: https://inventory-service-xyz.a.run.app/api/reserve
            auth:
              type: OIDC
            body:
              orderId: ${orderId}
          result: inventoryResult
        retry:
          predicate: ${http.default_retry_predicate}
          max_retries: 5
          backoff:
            initial_delay: 2
            max_delay: 60
            multiplier: 2

    - processPayment:
        try:
          call: http.post
          args:
            url: https://payment-service-xyz.a.run.app/api/charge
            auth:
              type: OIDC
            body:
              orderId: ${orderId}
              amount: ${amount}
          result: paymentResult
        except:
          as: e
          steps:
            - compensateInventory:
                call: http.post
                args:
                  url: https://inventory-service-xyz.a.run.app/api/release
                  auth:
                    type: OIDC
                  body:
                    orderId: ${orderId}
            - failWorkflow:
                raise: ${e}

    - notifyCustomer:
        call: http.post
        args:
          url: https://notification-service-xyz.a.run.app/api/send
          auth:
            type: OIDC
          body:
            email: ${customerEmail}
            status: "ORDER_CONFIRMED"
        result: notificationResult

    - returnSuccess:
        return:
          status: "COMPLETED"
          orderId: ${orderId}

---

Retrying Business Operations Safely

max_retries: 5 allows five retries after the initial call, so up to six attempts. The retry policy is a sibling of try, not a field nested inside its HTTP arguments. A retry predicate must be defined or imported; use ${http.default_retry_predicate} for the documented idempotent HTTP status set. The reserve-inventory endpoint must deduplicate by orderId, or a retry could reserve the same stock twice. Compensating release and refund endpoints also need stable idempotency keys.

Choreography vs. Orchestration Decision Framework

Architecting distributed systems requires choosing between Choreography (Eventarc, Pub/Sub) and Orchestration (Cloud Workflows).

The Saga Pattern in Cloud Workflows

In microservice architectures, distributed transactions across independent databases cannot use traditional ACID two-phase locking. The Saga Pattern manages distributed transactions by breaking them into a sequence of local transactions. If any step fails, Cloud Workflows coordinates compensating transactions in reverse order (as demonstrated in the YAML example above: releasing inventory if payment capture fails), restoring eventual data consistency across all microservice boundaries.

Official references checked October 18, 2026: Google Cloud 1.