Start with the simple idea: something happens, and something else needs to know about it.

The problem with asking again and again

Software has always needed to react to changes. A file arrives. A payment succeeds. A virtual machine is created. A message lands in a queue. In the early days, programmers solved this with polling. Polling means a program wakes up on a timer and checks whether anything new has appeared. It is like walking to your front door every two minutes to see if the postman is there.

Polling has three big problems. First, it wastes work, because most checks find nothing. Second, it is slow, because the news is only discovered at the next check. Third, it is hard to scale, because a thousand programs polling a thousand places create a thousand times the noise.

So what is Eventarc?

Eventarc is a fully managed Google Cloud service for building event-driven architectures. “Fully managed” means Google runs the servers, patches them, scales them and keeps them available. You only describe what you want: “When this happens over there, send a message to that service over here.”

It can pick up events from several families of sources: Google Cloud services themselves, messages published to Pub/Sub, your own applications, and certain partner products. It then routes each matching event to a destination, such as a Cloud Run service, a Cloud Run function, a Workflows execution or a service on Google Kubernetes Engine (GKE). It wraps every event in a common shape called a CloudEvent, so your code sees the same kind of envelope no matter where the event came from.

A short history

Before Eventarc, Google Cloud already had triggers, but they were scattered. Cloud Functions had its own built-in triggers for storage and Pub/Sub. Cloud Run, which runs containers, had no easy way to say “start me when a file lands in a bucket.” Developers glued things together by hand using logging sinks and Pub/Sub topics.

Eventarc appeared in preview around 2020 and reached general availability in 2021. Its goal was to give every destination the same trigger experience, built on an open industry standard called CloudEvents, which is maintained by the Cloud Native Computing Foundation. Over time Google added support for more event sources and, more recently, a second edition called Eventarc Advanced with a central “bus,” message transformation and more flexible routing. You will meet both editions in this guide.

Why teams choose it

Teams reach for Eventarc because it removes plumbing. Without it, you would create a Pub/Sub topic, set up a log sink, write filter rules, create push subscriptions, configure authentication, and then write code to unwrap everything. With Eventarc you declare a trigger and a destination, and the platform builds and manages the pipework for you.

A handful of words show up everywhere. Learn them once and the rest of the guide becomes easy.

Event, producer, router and consumer

An event is a small record that says “this thing happened at this time.” It is a fact about the past, such as “file report.pdf was created in bucket invoices” or “a new message was published to topic orders.” An event does not tell anyone what to do. It simply reports what occurred.

The part of the system where the event happens is the producer (also called the source or publisher). The part that reacts is the consumer (also called the handler, receiver or destination). In between sits the router, which decides who should hear about which event. Eventarc plays the router.

Trigger, filter and payload

A trigger is the rule you create in Eventarc. It says: listen for events that match these conditions, and deliver them to this destination. The conditions are called filters. A filter might say “only events of type ‘object finalized’ from the bucket named photos-uploads.” Events that do not match are simply ignored by that trigger.

The payload (sometimes called the data) is the detailed content of the event, such as the file name, size and time. The metadata (the label on the outside) tells you the event’s type, where it came from and when it happened.

Coupling: why this style is popular

Coupling is how tightly two parts of a system depend on each other. In a tightly coupled design, the upload service must know about the thumbnail service, the safety checker and the notification sender, and must call each one directly. If one is slow or broken, the upload service suffers. In an event-driven design, the upload service just announces “a photo arrived.” Anyone who cares can listen. You can add a fifth listener tomorrow without touching the upload service at all. This is called loose coupling.

A quick glossary table

Events versus commands

One subtle point trips up many beginners. An event says “this happened”. A command says “please do this.” Eventarc carries events. If you name your events like commands, for example “ResizeThisImage,” your design slowly becomes tightly coupled again, because the producer now secretly depends on what the consumer does. Good event names look like past-tense facts: “ImageUploaded,” “OrderPlaced,” “VmCreated.”

The original and most widely used edition of Eventarc is called Standard. It is built around triggers.

Two editions in one product

Eventarc comes in two editions. Eventarc Standard is the long-established one. You create triggers, and each trigger connects one kind of event to one destination. Eventarc Advanced adds a central bus, pipelines and enrollments, plus message transformation. This chapter covers Standard. Chapter 8 covers Advanced.

The building blocks of a Standard trigger

Event providers

An event provider is the kind of source that produces events. Eventarc Standard groups providers into a few families, which the next chapter explains in detail: direct events from Google Cloud services, events built from Cloud Audit Logs, events from Pub/Sub, and events from third-party providers.

Locations matter

Every trigger lives in a location. Think of it as the trigger’s home address. For many event types the trigger must live in the same region as the thing it watches. If your bucket lives in one region, your trigger usually belongs in that region too. Some event families can use a “global” location. Choosing locations carefully keeps delivery fast, helps with data-residency rules (laws or company policies about where data may be processed) and avoids confusing errors when a trigger will not create.

Channels for outside providers

When an event comes from a partner company’s product rather than from Google Cloud, a direct line is needed. A channel is that line. The partner publishes into the channel, and your triggers can then listen to it. This lets you react to events from monitoring, security or other software-as-a-service tools in the same way you react to a storage upload. The list of supported partners changes over time, so always check the current documentation before planning around one.

Choosing the right kind of source is the first design decision, and it affects speed, cost and reliability.

1. Direct events from Google Cloud

Some Google Cloud services publish events straight to Eventarc. These are called direct events. Examples include Cloud Storage reporting that an object was finalized or deleted, and several other products such as Firestore, Cloud Build, Artifact Registry and Firebase services. The exact list grows over time.

Direct events are usually the best choice when one is available. They are quick, because there is no middle step, and they carry a clear, purpose-built payload that describes the change.

2. Cloud Audit Logs events

Cloud Audit Logs is Google Cloud’s record of “who did what, where and when.” Whenever someone calls an API, such as creating a VM, changing a firewall rule or reading a dataset, an audit entry can be written. Eventarc can turn a matching audit entry into an event. This gives you a way to react to a very wide range of actions across dozens of Google Cloud services, even those that do not publish direct events.

There are two kinds of entries. Admin Activity logs record changes to configuration and are on by default. Data Access logs record reads and writes of user data. These are often off by default for most services, so you must turn them on before a trigger can use them. Turning them on can increase logging volume and cost, so do it only where needed.

3. Pub/Sub messages

Pub/Sub is Google Cloud’s messaging service, where publishers send messages to a topic and subscribers receive them. An Eventarc trigger can listen to a Pub/Sub topic and deliver each message to a destination as a CloudEvent. This is the natural choice for your own custom events: your application publishes “OrderPlaced” to a topic, and Eventarc routes it onward.

4. Third-party providers

Partner products can publish events into your project through a channel, as covered in the last chapter. This is helpful when important signals originate outside Google Cloud.

Comparing the families

A destination is the code or service that receives the event and does the actual work.

Cloud Run services

Cloud Run runs your containers without you managing servers. When an event arrives, Eventarc sends it to your service as an ordinary web request (an HTTP POST). Your service reads the request, does its job and replies with a success code. Cloud Run can scale from zero copies to many, so a quiet period costs almost nothing and a sudden burst of events is handled by starting more copies.

Cloud Run functions

Cloud Run functions (the newer name for second-generation Cloud Functions) let you write a small piece of code that runs when an event arrives, without thinking about containers at all. Under the hood, event-driven functions use Eventarc triggers. This is the lightest way to react to a single event, such as writing a log line or updating a record.

Workflows

Workflows is Google Cloud’s orchestration service. It runs a series of steps in a defined order: call this service, wait, check the answer, call that service, handle errors. An Eventarc trigger can start a workflow execution and hand it the event as input. Use this when one event must start a multi-step process rather than a single action.

Google Kubernetes Engine (GKE)

If your applications run on GKE, Eventarc can deliver events to a service inside your cluster. This keeps event handling next to the rest of your Kubernetes workloads. It needs some extra setup on the cluster side, such as allowing the right identities to work with it, so follow the current setup guide for your cluster type.

Internal HTTP endpoints

Eventarc Standard can also deliver to an internal HTTP endpoint inside a private Virtual Private Cloud (VPC) network. A VPC is your own private, walled-off network inside Google Cloud. This is useful when the handler is not public on the internet and should stay private.

What the destination must do

Whatever you pick, the destination must follow one simple contract. It receives the event, does its work, and answers with a success status quickly. A success reply tells Eventarc “got it, you can stop.” Any failure reply, or no reply in time, tells Eventarc “try again later.” This simple handshake is the foundation of reliable delivery, which Chapter 10 explores.

Now put the pieces on one map, so you can see how an Eventarc Standard setup is built.

The big picture

Every Standard setup has the same basic shape. On the left are the sources. In the middle is Eventarc, with its trigger and delivery machinery. On the right are the destinations. Underneath, a Pub/Sub topic acts as the transport that carries events safely from the trigger to the delivery step.

flowchart LR
  A["Event Source: Cloud Storage, Audit Logs or Pub/Sub"] --> B["Eventarc Trigger with Filters"]
  B --> C["Transport Topic in Pub/Sub"]
  C --> D["Eventarc Delivery with Identity Token"]
  D --> E["Cloud Run Service"]
  D --> F["Cloud Run Function"]
  D --> G["Workflows Execution"]
  D --> H["GKE Service"]

Walking through the map

The event source is where the change happens. The trigger checks each incoming event against its filters. Matching events are placed onto a transport topic, which is a Pub/Sub topic that Eventarc creates and manages for you in most Standard setups. The transport topic gives you buffering and retry behaviour that you would otherwise have to build. The delivery step then pushes the event to the destination as an authenticated web request.

The identities involved

Three kinds of identity take part, and mixing them up is a very common source of errors.

• The trigger service account is the identity you choose. Eventarc uses it when delivering events, so it needs permission to receive events and to call your destination.
• The Eventarc service agent is a Google-managed identity that Eventarc uses behind the scenes to create and manage supporting resources.
• The destination’s own identity is what your handler uses when it calls other services after the event arrives.

Regional design

Eventarc resources are regional. The trigger, the transport topic and the destination are normally placed in the same region, or the trigger sits in a region that matches the source. Keeping everything close shortens the delivery path. For disaster planning, teams that need higher availability often create matching triggers and destinations in more than one region and design handlers that can safely process the same event twice.

What Eventarc does not do

It does not transform the content of your events in Standard (the Advanced edition adds this). It does not guarantee the order in which events arrive. It does not keep a permanent archive. Knowing these limits helps you decide what extra pieces you need.

Follow a single photo upload from the moment it happens to the moment it is fully handled.

The step-by-step journey

sequenceDiagram
  participant U as Customer
  participant S as Cloud Storage
  participant E as Eventarc Trigger
  participant P as Transport Topic
  participant H as Cloud Run Handler
  U->>S: Upload photo
  S->>E: Object finalized event
  E->>E: Match trigger filters
  E->>P: Place CloudEvent on topic
  P->>H: Deliver HTTP POST with identity token
  H-->>P: Reply with success status
  Note over P,H: If the reply fails or times out the delivery is retried with backoff

Push delivery

Eventarc pushes events to your destination. Your handler does not need to run a loop asking “anything new?” It simply waits for requests. Push delivery is why a Cloud Run service can scale down to nothing between events and wake up when one arrives.

Acknowledgement and retries

The success reply is called an acknowledgement. Until Eventarc receives one, it treats the event as not yet handled. When delivery fails, it tries again using exponential backoff, which means the pause between attempts grows each time, for example a short wait, then a longer one, then longer still. This protects a struggling handler from being flooded while it recovers. Retries are limited in time, with a default retention measured in about a day for Standard events carried by Pub/Sub, so an event that cannot be delivered for long enough is eventually dropped. Check current documentation for exact limits.

Why audit-log events are slower

Direct events go straight from the service to Eventarc. Audit-log events first need the action to be written to the log, then matched and forwarded. That extra hop is why audit-based triggers usually show higher delay. For tasks where seconds matter, choose a direct event or a Pub/Sub message if you can.

The Advanced edition keeps the same goal but changes the shape: one central place where events gather, and flexible rules that decide where they go.

Why a second edition?

In Standard, each trigger connects one source to one destination. That is simple, but in a large company it can lead to hundreds of separate triggers that are hard to see as a whole. Teams also wanted to change the shape of an event before delivery, collect events from many places in one spot, and share a stream across teams. Eventarc Advanced was built for these needs.

The three new building blocks

flowchart LR
  S1["Google API Source"] --> B["Message Bus"]
  S2["Your Application via Publishing API"] --> B
  B --> N1["Enrollment A with Match Rule"]
  B --> N2["Enrollment B with Match Rule"]
  B --> N3["Enrollment C with Match Rule"]
  N1 --> P1["Pipeline 1 with Transformation"]
  N2 --> P2["Pipeline 2"]
  N3 --> P3["Pipeline 3"]
  P1 --> D1["Cloud Run Service"]
  P2 --> D2["Workflows"]
  P3 --> D3["Pub/Sub Topic"]

Transformation

A pipeline can change an event before it reaches the destination. Why does this matter? Imagine an older handler that expects a certain format, while the source sends another. Instead of writing glue code, you let the pipeline convert the message. This is especially handy when connecting systems built by different teams at different times.

Standard versus Advanced

Every event Eventarc delivers wears the same kind of envelope, so your code always knows where to look.

What is CloudEvents?

CloudEvents is an open specification that describes how to label an event. Without a shared standard, every service invents its own labels, and every handler needs special code for each one. With CloudEvents, a small set of standard labels sits on the outside, and the service-specific details sit on the inside.

The standard labels

How the envelope reaches your handler

For Eventarc triggers that deliver by HTTP, the CloudEvents labels usually arrive as web request headers, and the payload arrives in the request body. This style is called binary content mode. Another style puts both labels and data together in the body, called structured content mode. Your handler can read either, and many ready-made libraries for CloudEvents do the unpacking for you.

Use the id to spot duplicates

Because delivery is at-least-once, the same event can show up twice. The id label is your friend here. Your handler can note the ids it has already processed and skip any repeat. This idea has a name, idempotency, which Chapter 10 explains.

The data inside

The data section is specific to the source. A storage event carries bucket and object details. A Pub/Sub event carries the message and its attributes. An audit-log event carries the log entry describing the API call, including who made it and which resource was affected. Read the documentation for the event type you use, since field names and shapes differ.

This is the chapter that separates a demo from a dependable production system.

The three delivery promises

Messaging systems usually offer one of three promises. At-most-once means an event is delivered zero or one time, so it can be lost but never repeated. At-least-once means it is delivered one or more times, so it is never lost on purpose but may be repeated. Exactly-once means one time only, which is extremely hard to guarantee across separate systems. Eventarc follows the at-least-once model, so your handler should be ready for repeats.

Idempotency: doing the same thing twice safely

A handler is idempotent when running it twice has the same final effect as running it once. Setting a light switch to “on” is idempotent: pressing “set to on” ten times leaves the light on. Adding one to a counter is not: ten presses give ten. Many real tasks can be made idempotent with small tricks.

• Record each event id in a table, and skip an id you have seen before.
• Use “create or replace” style writes that end in the same state however many times they run.
• Give each result file a name based on the event id, so a repeat overwrites the same file instead of creating a second one.
• Use a unique key in the database so a second insert is rejected.

Ordering is not guaranteed

Events can arrive in a different order from the one in which they happened. A “file deleted” event might reach you before the “file created” event for the same file, especially after a retry. Handlers should look at the time label and, where it matters, check the current state of the resource before acting. If strict order is vital, you may need a design that includes a sequence number or a source that supports ordered delivery.

Failures and what happens next

Planning for events you cannot afford to lose

Retries buy time, not forever. For events that truly must not be lost, such as financial records, design a safety net. A common approach is to have your handler save the raw event to a durable place first, such as a Pub/Sub topic with a dead-letter topic (a special topic where messages that keep failing are parked for later inspection) or a database table, and then process it. In the Advanced edition, pipelines expose retry settings, so review the options available to you. A scheduled repair job that compares “what should exist” with “what does exist” is also a wise backup.

Poison events and the quiet drop

A poison event is one that your code can never handle, for instance because it has a missing field. If your handler replies with an error every time, retries burn resources until the window closes. A kinder approach is to detect the problem, write the event to an “inspect later” place, and reply with success so the system moves on.

Events can carry sensitive information and can start powerful actions, so every step needs a lock.

Identity and Access Management (IAM)

IAM is Google Cloud’s permission system. It answers the question, “Who is allowed to do what to which resource?” Permissions are grouped into roles, and roles are given to principals such as users and service accounts. A service account is an identity for a program rather than a person.

The roles that make triggers work

For a Standard trigger delivering to Cloud Run, the trigger’s service account generally needs two kinds of permission: the right to receive events through Eventarc (the Eventarc Event Receiver role) and the right to invoke the destination (for Cloud Run, the Cloud Run Invoker role). The person creating the trigger also needs permission to create it and to act as the service account. Exact roles can change, so use the current setup guide for your destination type.

Authenticated delivery

Eventarc signs each delivery with an identity token (an OpenID Connect or OIDC token) created for the trigger’s service account. Your destination service checks this token. Cloud Run does the checking for you when you keep the service private and require authentication. The result is that only Eventarc, acting as the identity you chose, can send events to your handler.

Least privilege

The principle of least privilege says give each identity only the permissions it truly needs. Create a dedicated service account for each trigger or group of similar triggers, rather than reusing a powerful, shared one. If a single account is compromised, the damage stays small.

Do not leave the door open

A common beginner shortcut is to allow unauthenticated calls to a Cloud Run service so that everything “just works.” This means anyone on the internet could send fake events to your handler. Keep authentication on, and let only the trigger’s service account call it.

Audit logs and sensitive operations

Audit-log triggers are a powerful security tool. You can react when a firewall rule is changed, a storage bucket is made public, or a service account key is created, and automatically start a repair or send an alert. Remember that enabling Data Access logs adds volume and may contain sensitive details, so control who can read those logs.

Network controls and data protection

• Private destinations: Standard can deliver to internal endpoints inside a VPC, so handlers need not be public.
• VPC Service Controls: A feature that draws a protective boundary around Google Cloud services to reduce the chance of data leaving. Check the current compatibility notes for the event types you use.
• Encryption: Data is encrypted in transit and at rest by default. Customer-managed encryption keys (CMEK) are supported in some configurations when your rules require your own keys.
• Organization policies: Rules set at the company level can limit where resources are created, which interacts with trigger locations.

An event system works quietly. That is a gift when it works and a trap when it fails, because nobody notices silence.

Three questions to answer

Good monitoring of an event pipeline answers three simple questions. Are events arriving? Are they being handled successfully? Are they handled quickly enough? Every dashboard and alert you build should map to one of these.

Where to look

Alerts worth having

• A rise in the error rate of the destination service.
• A growing backlog, meaning events are waiting longer than usual.
• A drop to zero events when you normally see a steady flow. Silence can be a failure too.
• Latency beyond what your business can tolerate, measured from event time to finished work.

Correlation: following one event

When something goes wrong at 3 a.m., you will want to ask, “What happened to the event for order 12345?” That is only possible if you planned for it. Put the CloudEvent id and any business key, such as an order number, into your logs. Pass them along to any next service you call. With these two habits, a search for one id gives the full story.

Cost awareness

Pricing for Eventarc differs between the Standard and Advanced editions, and between event families, so read the current pricing page before you plan at large scale. Remember the hidden costs around it: Cloud Run request time, Pub/Sub usage, Cloud Logging volume (especially Data Access audit logs) and calls to downstream databases. A noisy trigger with weak filters can create real bills fast.

No tool is perfect. A fair look at both sides helps you decide when Eventarc is the right fit.

The big trade-offs in plain words

Simplicity against control. Eventarc hides the plumbing, which makes it simple. In return, you cannot tune every low-level detail the way you could with your own Pub/Sub subscriptions or a self-run broker.

Speed against coverage. Direct events are fast but limited to certain services. Audit logs reach nearly everything but arrive later.

Loose coupling against visibility. When many small pieces react to events, no single place shows the whole flow. Without good naming, logging and diagrams, debugging gets harder. Event-driven systems trade easy-to-see code paths for flexibility.

Reliability against cost. Adding backups such as dead-letter topics, state tables and repair jobs makes the system sturdier but adds cost and moving parts.

A pattern is a proven way to solve a common problem. An anti-pattern is a tempting mistake that causes trouble later.

Useful patterns

Anti-patterns to avoid

flowchart LR
  A["Bucket"] -->|"object finalized"| B["Eventarc Trigger"]
  B --> C["Cloud Run Handler"]
  C -->|"writes result into same bucket"| A

A short checklist you can use on your next build.

Best practices

Common mistakes

A simple troubleshooting order

When events do not arrive, check in this order: first, is the source really producing events (and are any needed audit logs on)? Second, does the trigger’s location and filter match? Third, does the service account have the right roles? Fourth, is the destination reachable and returning success? Fifth, what do the destination’s logs say about the request? Following the same path each time turns panic into a routine.

These typical situations show how companies of many kinds use event-driven designs on Google Cloud. They are illustrative patterns, not accounts of any one company’s private setup.

Google Cloud has several services that move messages or start work. Knowing the differences prevents using the wrong one.

Eventarc and Pub/Sub together

These two are friends, not rivals. Pub/Sub is the pipe system underneath, and Eventarc is the smart junction that connects many sources to many destinations. Choose Eventarc when you want the simple, managed trigger experience. Choose plain Pub/Sub when you need fine control over how messages are pulled, grouped or ordered.

If you know other clouds

Readers who know other clouds may find a loose comparison helpful. The Advanced edition, with its bus and rules, plays a role similar to the event bus services found on other major clouds, while Standard triggers are closer to the simple “when this happens, run that” rules. The match is not exact, so rely on Google Cloud’s own documentation for details.

What happens when ten events a day become ten million? This chapter explains how the pieces behave under pressure and how to keep them dependable.

Where the time goes

The time between “something happened” and “work finished” is called end-to-end latency. It is made of several smaller delays added together: the source noticing the change, Eventarc matching and storing the event, the delivery request travelling to the destination, the destination starting up if it was asleep, and finally your own code running. Knowing the parts helps you find which one is slow.

• Source delay: Direct events are quick. Audit-log events wait for the log entry to be written first.
• Routing delay: Matching filters and placing the event on the transport topic is usually small compared with the rest.
• Cold start: A Cloud Run service that has scaled to zero needs a moment to start a fresh copy when the first event arrives. This pause is called a cold start.
• Handler time: Your own code, plus any database or network calls, is very often the biggest part.

Scaling up when events pile in

Eventarc itself is a managed service, so you do not add servers to it. The part you must plan for is the destination. Cloud Run starts more copies as more requests arrive, up to limits you can set. If a flood of events arrives, the transport topic holds events while the destination catches up, and delivery speeds up as more copies become available. Eventarc also slows down pushing events when it sees a destination returning errors, to avoid making a bad situation worse.

The hidden danger is not Cloud Run but what sits behind it. Suppose each handler opens a connection to a database that allows only a hundred connections. If Cloud Run starts five hundred copies, four hundred of them will fail. The fix is to cap the number of copies to what the database can take, share connections through a pooling layer, or place a queue in front of the slow part so work flows through at a steady rate.

Back-pressure: letting the system breathe

Back-pressure means the slow part of a system tells the fast part to ease off. In an event flow, the retry-with-backoff behaviour is a gentle form of back-pressure. If your handler answers with errors, deliveries slow down. For heavy jobs, a better design is to accept events quickly, drop them into a Cloud Tasks queue or a Pub/Sub subscription with a controlled pull rate, and process them at the pace your downstream systems like.

Throughput and cost go hand in hand

Every event that wakes a handler costs a little: request time on Cloud Run, a share of the messaging behind the scenes, and a few log lines. At small scale these costs are tiny. At millions of events per day they become a real line on the bill. Two habits keep them in check. First, filter so that only useful events reach a handler. Second, keep each handler short and efficient, because the time your code runs is the time you pay for. A handler that finishes in fifty milliseconds instead of five hundred does ten times as many jobs for the same money, and it frees up capacity for the next burst.

Batching can help in some designs. If your task is “add a row to a report,” doing one database write per event may be wasteful. A common approach is to collect many events into a small holding area and write them together every few seconds. The trade-off is a little more delay and a little more complexity, so only add batching when measurements show you need it.

High availability

High availability means the system keeps working even when parts fail. Eventarc is a regional managed service, and Google runs it across several zones within a region, so the loss of a single data centre room does not stop it. Your own design adds to this in a few ways.

• Run your destination in a regional service that spreads copies across zones, which Cloud Run does by default.
• Make handlers idempotent so that retries after a partial failure are harmless.
• For the most important flows, consider a second region with its own trigger and destination, and decide ahead of time how the two regions avoid doing the same work twice.
• Keep a repair job that can rebuild missing results by comparing the source of truth with the outputs.

Capacity planning in simple steps

Let us put everything together by designing, on paper, an image-processing flow for the photo-printing shop from the start of this guide.

Step 1: Write the story in one sentence

“When a customer uploads a photo, we want a web-sized copy made, a safety check run, and a record saved, and we must never charge for or print the same photo twice.” This one sentence names the event (an upload), the actions (three of them) and a rule (no repeats). Writing it down first prevents much confusion later.

Step 2: Pick the source

Uploads land in Cloud Storage, and Cloud Storage publishes a direct event when an object is finalized. That is the best choice: fast, purpose-built and no log settings needed.

Step 3: Choose the edition

There are only a few reactions and one team, so Eventarc Standard is enough. If five other teams later want to listen to uploads and each needs a different data shape, the design can move to Advanced.

Step 4: Decide how many handlers

The three actions have different speeds and different failure risks. The resizing is quick. The safety check calls an outside service and may be slow. The record-saving must never fail silently. Using fan-out, three separate triggers with the same filter send each upload to three small handlers. If the safety check is slow or down, the thumbnail and the record are still done.

flowchart LR
  U["Customer Upload"] --> B["Upload Bucket"]
  B --> T1["Trigger One"]
  B --> T2["Trigger Two"]
  B --> T3["Trigger Three"]
  T1 --> H1["Resizer Handler"]
  T2 --> H2["Safety Check Handler"]
  T3 --> H3["Record Keeper Handler"]
  H1 --> O["Separate Output Bucket"]
  H3 --> D["Database"]

Step 5: Protect against the known traps

Step 6: Plan the safety net and the watching

Failed events for the record keeper are saved to a durable parking place for review. A scheduled check once a night compares the list of uploads with the list of records and repairs any gaps. Dashboards track upload events arriving, handler errors, and the age of the oldest waiting event. An alert fires if no events arrive for an hour during business hours.

The design checklist

Quick answers to the questions that come up most often.

No. Pub/Sub is a messaging service. Eventarc is an event router that often uses Pub/Sub underneath. It adds filtering, standard event formats, many sources and ready-made delivery to destinations.

No. Delivery is at-least-once, so duplicates are possible. Design handlers to be idempotent.

No. Treat order as unreliable. Use the event time and the current state of the resource when order matters.

Eventarc retries with growing pauses for a limited time. If your handler recovers in time, the events are delivered. If the outage outlasts the retry window, events can be lost, so add a safety net for critical data.

The most common reasons are that Data Access logs were not turned on, the method name or resource filter did not match, the location was wrong or the service account lacked permission.

Yes. In Standard, create several triggers with the same filter. In Advanced, several enrollments on one bus can each send matching events to their own pipelines.

Event-driven Cloud Run functions use Eventarc triggers behind the scenes, so you are already using it even if the setup screens look simpler.

Yes. In Standard, publish to a Pub/Sub topic and trigger from it. In Advanced, applications can publish CloudEvents to a bus.

Limits exist and depend on the source and edition. A good habit is to keep events small and send pointers to large data. Check the current quotas page for exact figures.

Start with Standard for simple reactions. Consider Advanced when you need a shared bus, transformation or many teams working from one event stream.

Pricing depends on the edition and event type, and may change. Beyond Eventarc itself, you also pay for destinations, Pub/Sub use and logging. Read the current pricing page and estimate with your expected event volume.

Never let a handler write its output where its own trigger is listening. Use a separate bucket or topic, or check for and skip your own output.

The whole guide in one place.