Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Invoking Cloud Run services using triggers (e.g., Eventarc, Pub/Sub)
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
When Cloud Run services respond to events from sources like Pub/Sub or Eventarc, the system must handle failures gracefully. A retry policy automatically attempts to deliver a message again when the first try fails. If a message keeps failing after several attempts, it moves to a dead-letter queue where developers can review it later. This prevents one bad message from stopping the entire system.
Because events might arrive more than once due to automatic retries, services must process events in an idempotent way. An idempotent service produces the same result whether it handles a message once or multiple times. This prevents duplicate records or wrong data in your database.
For data that lives in multiple places, developers choose between different replication strategies. Synchronous replication writes to multiple locations at once for the strongest consistency. Asynchronous replication is faster but may create conflicts if data changes in two places simultaneously. Multi-region deployments protect against regional outages by running services in different geographic areas.
Eventarc routes events from various Google Cloud sources to destinations like Cloud Run. Events follow the CloudEvents standard, which gives every event a consistent format that any application can understand.
You create an Eventarc trigger to define which events reach your service. Triggers connect to different event providers:
Each trigger specifies an event provider and the specific event type that should start the process.
Filters narrow down which events actually reach your service. You might filter to a specific storage bucket or a particular action name. This separates application parts so they only run when needed, helping the system scale efficiently.
The service account running the trigger needs the Cloud Run Invoker role to call your service. It also needs the Eventarc Event Receiver role to receive events from providers. Without these permissions, the trigger fails.
Place your trigger, the event source, and your Cloud Run service in the same Region to reduce delay. While triggers create quickly, allow up to two minutes for the full configuration to take effect.
Event-driven architecture lets applications react automatically to changes like new messages or file uploads. In Google Cloud, Eventarc connects these events to Cloud Run services so your code runs only when triggered.
A Pub/Sub push subscription sends messages directly to a URL on your Cloud Run service. You configure the event provider (such as Pub/Sub), the event type (a message published to a topic), and the destination Cloud Run service.
Cloud Run services stay private by default. To let a trigger call your service, grant the Cloud Run Invoker role to the trigger's service account. Without this permission, requests fail with "unauthenticated" errors.
The service account acts as the trigger's identity when making requests to your service. While the default Compute Engine service account works for testing, create a custom service account for production. This follows the principle of least privilege, giving only the exact permissions needed.
Keep the trigger, event source, and Cloud Run service in the same Region to minimize latency. Also ensure the Pub/Sub service agent has the Service Account Token Creator role to generate the OIDC tokens needed for secure message delivery.