Eventarc lets you build event-driven and message-based architectures without having to implement, customize, or maintain the underlying infrastructure.
Eventarc is offered in two editions: Eventarc Advanced and Eventarc Standard. Both editions offer a scalable, serverless, and fully managed eventing solution that lets you asynchronously route events from sources to targets. For more information, see Choose Eventarc Advanced or Eventarc Standard.
Eventarc Advanced is designed to simplify the ingestion, orchestration, and delivery of event data through messages across applications, services, and endpoints. Eventarc Advanced lets you collect events that occur in a system and publish them to a central bus. Interested services can subscribe to specific messages by creating enrollments. You can use the bus and a pipeline to route events from multiple sources in real time, publish them to multiple destinations, and optionally transform events prior to delivery to a target.
Eventarc Advanced is ideal for organizations with complex eventing and messaging needs, particularly those grappling with managing numerous Pub/Sub topics, Kafka queues, or other third-party messaging systems. By providing administrators with enhanced and centralized visibility and control, Eventarc Advanced enables organizations to connect multiple teams across different projects.
You can manage Eventarc Advanced from the Google Cloud console, from the command line using the Google Cloud CLI, or by using the Eventarc API.
between different services, apps, and systems (click diagram to enlarge).
Key concepts
A bus provides a discoverable endpoint for events and is a router that receives all events published by providers and delivers them to zero or more destinations. A bus lets you centralize, monitor, and trace the flow of messages through your system. You can use a bus to route events from many sources to many targets.
Messages that arrive at a bus are evaluated according to the criteria of an enrollment which represents a subscription for events collected by a particular bus. The events are routed to consumers who have subscribed to those specific events. The enrollment lets you use Common Expression Language (CEL) to define fine-grained access control policies by matching events based on event attributes. An enrollment also lets you specify the pipeline to which matched events should be delivered.
The pipeline is the delivery intermediary between a bus and a destination. The pipeline specifies a target destination and also provides the option of transforming any matched events prior to delivering them to the destination. It lets you handle different event structures by supporting multiple payload formats and by letting you adapt event data on the fly without modifying your source or target services.
Key capabilities
Eventarc Advanced supports many use cases for destination applications. Some key capabilities are:
Large-scale application integration: You can connect numerous services and applications, enabling asynchronous communication across different event formats and schemas.
Event streaming for AI and analytics: You can handle the influx of data from IoT devices and AI workloads, filtering, transforming, and enriching events before feeding them into your analytics pipelines.
Hybrid and multi-cloud deployments: You can extend your event-driven architectures beyond Google Cloud, integrating with on-premise systems and other cloud providers. Eventarc Advanced lets you route events from various sources including Google sources and direct publishers of events.
Understand regionality
Eventarc Advanced is a fully regional service: all Eventarc Advanced traffic and data must reside in the same region. For example, enrollments and pipelines can only read and process data from the same region as the bus. Cross-regional support can be achieved by publishing events to different buses in different regions, and by configuring a network within a service perimeter that spans multiple regions.
Project layouts
All Eventarc resources must belong to a Google Cloud project. However, there is no requirement for the provider (event source), bus (administrator), and pipeline (event target) to be in the same project.
You can use a combination of Identity and Access Management (IAM) permissions to control resource usage, fine-grained access to data using CEL, network attachments, and service perimeters to support networking and security requirements for different ingress and egress needs.
Events
An event is a data record that expresses an occurrence and its context, and indicates a change in a resource or environment. An event is a discrete unit of communication, independent of other events. For example, an event might indicate a change to data in a database, a file added to a storage system, or a scheduled job.
Note that an event is also a message emitted by a component when its state has changed. When an event occurs, the message is sent to the eventing infrastructure where consumers can retrieve it. In the context of event-driven architecture, we often use the term event to refer to the message that communicates the event rather than to the occurrence itself (what actually happened to generate the message).
Event types
Eventarc Advanced supports events that come directly from a Google source.
For more information, see Google event types supported by Eventarc.
Event providers and destinations
Events are collected from event providers by Eventarc Advanced and routed to an event destination. Each Eventarc Advanced pipeline can specify only one destination as its target for routed messages.
Supported providers include Google providers and direct publishers of events. Supported destinations include Cloud Run, Cloud Run functions, HTTP endpoints hosted in a Virtual Private Cloud network, Workflows, and another Eventarc Advanced bus.
For more information, see Event providers and destinations.
Event format and libraries
Eventarc delivers events, regardless of provider, to the target destination in a CloudEvents format using an HTTP request in binary content mode. CloudEvents is a specification for describing event metadata in a common way.
Target destinations such as Cloud Run functions and Cloud Run consume events in the HTTP format. For Workflows destinations, the Workflows service converts the event to a JSON object, and passes the event into the workflow execution as a runtime argument.
Using a standard way to describe event metadata ensures consistency, accessibility, and portability. Event consumers can read these events directly, or you can use the Cloud Client Libraries in various languages (including C++, C#, Go, Java, Node.js, PHP, Python, and Ruby) to read and parse the events. There is also a set of language-specific CloudEvents SDKs.
The structure of the HTTP body for all events is available in the Google CloudEvents GitHub repository.
Reliability and delivery
There is no in-order, first-in-first-out delivery guarantee. Note that having strict ordering would undermine Eventarc's availability and scalability features which match those of its transport layer, Pub/Sub. For more information, see Ordering messages.
Latency and throughput are best effort. They vary based on multiple factors, including whether publishing or egress traffic involves different regions; the configuration of a particular service; and the network load on resources in a Google Cloud region.
Note that there are usage quotas and limits that apply generally to Eventarc.
Event retry policy
The default message retention duration set by Eventarc Advanced is 24 hours with an exponential backoff delay.
Eventarc Advanced uses an exponential backoff delay to handle errors that can be retried. This starts with a one-second delay and the delay is doubled after each failed attempt (up to a maximum of 60 seconds and 5 attempts).
For more information, see Retry events.
Duplicate events
Duplicate events might be delivered to event handlers. According to the
CloudEvents specification,
the combination of source and id attributes is considered unique, and
therefore any events with the same combination are considered duplicates.
You should implement
idempotent event handlers
as a general best practice.
Observability
Detailed logs for Eventarc, Cloud Run, Cloud Run functions, Pub/Sub, and Workflows are available from Cloud Audit Logs.