Eventarc for event routing in GCP - Time & Space Complexity
When using Eventarc to route events, it is important to understand how the number of events affects processing time.
We want to know how the system handles more events and how the routing time changes.
Analyze the time complexity of the following event routing setup.
// Create an Eventarc trigger
const trigger = eventarc.triggers.create({
name: 'my-trigger',
eventFilters: [{ attribute: 'type', value: 'google.cloud.storage.object.v1.finalized' }],
destination: { cloudRunService: 'my-service', region: 'us-central1' }
});
// Events arrive and are routed to the destination
// Each event is processed individually
This setup routes storage object finalized events to a Cloud Run service.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Routing each incoming event to the destination service.
- How many times: Once per event received.
As the number of events increases, the routing operation happens for each event separately.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 routing operations |
| 100 | 100 routing operations |
| 1000 | 1000 routing operations |
Pattern observation: The number of routing operations grows directly with the number of events.
Time Complexity: O(n)
This means the time to route events grows linearly with the number of events.
[X] Wrong: "Routing multiple events happens all at once, so time stays the same no matter how many events arrive."
[OK] Correct: Each event is routed individually, so more events mean more routing operations and more time.
Understanding how event routing scales helps you design systems that handle growing workloads smoothly.
"What if we batch events before routing? How would the time complexity change?"
Practice
Solution
Step 1: Understand Eventarc's role
Eventarc is designed to listen for events from various cloud services and route them to your applications automatically.Step 2: Compare options
Options A, B, and D describe other cloud services like storage, compute, and IAM, which are not Eventarc's purpose.Final Answer:
To route events from cloud services to your applications automatically -> Option CQuick Check:
Event routing = To route events from cloud services to your applications automatically [OK]
- Confusing Eventarc with storage services
- Thinking Eventarc manages virtual machines
- Mixing Eventarc with user permission management
Solution
Step 1: Identify Eventarc trigger creation syntax
The correct command uses 'gcloud eventarc triggers create' with destination and event filters.Step 2: Eliminate unrelated commands
Options B, C, and D relate to compute, storage, and IAM, not Eventarc triggers.Final Answer:
gcloud eventarc triggers create my-trigger --destination-run-service=my-service --event-filters=type=google.cloud.pubsub.topic.v1.messagePublished -> Option BQuick Check:
Eventarc trigger creation uses 'gcloud eventarc triggers create' [OK]
- Using compute or storage commands instead of eventarc
- Missing event-filters parameter
- Incorrect destination flag
{
"name": "projects/my-project/locations/us-central1/triggers/my-trigger",
"destination": {
"cloudRunService": {
"service": "my-service",
"region": "us-central1"
}
},
"eventFilters": [
{"attribute": "type", "value": "google.cloud.storage.object.v1.finalized"}
]
}What event will this trigger listen for?
Solution
Step 1: Analyze eventFilters attribute
The filter type is 'google.cloud.storage.object.v1.finalized', which means when a Cloud Storage object is finalized (created or overwritten).Step 2: Match event type to options
This corresponds to new or updated objects in Cloud Storage buckets, not Pub/Sub, Compute Engine, or Cloud SQL events.Final Answer:
New objects finalized (created) in Cloud Storage buckets -> Option AQuick Check:
Storage object finalized event = New objects finalized (created) in Cloud Storage buckets [OK]
- Confusing storage events with Pub/Sub messages
- Assuming compute or database events
- Ignoring eventFilters attribute
Solution
Step 1: Check event filter correctness
If the event filter type does not match any events, no events will be routed to the service.Step 2: Consider other options
While region mismatch or wrong project can cause issues, the most common cause is incorrect event filter type. CPU allocation does not prevent event delivery.Final Answer:
The trigger's event filter type does not match any events being emitted -> Option DQuick Check:
Event filter mismatch blocks events [OK]
- Ignoring event filter mismatch
- Assuming CPU allocation affects event routing
- Not verifying project and region settings
Solution
Step 1: Understand Eventarc trigger event filters
Each Eventarc trigger supports filtering on one event type. To listen to multiple event types, separate triggers are needed.Step 2: Evaluate options
Create a single Eventarc trigger with multiple event filters for both Cloud Storage and Pub/Sub events is invalid because a single trigger cannot filter multiple event types. Create one trigger for Cloud Storage and configure Pub/Sub to push messages directly to Cloud Run without Eventarc bypasses Eventarc for Pub/Sub, losing unified routing. Use Cloud Scheduler to poll both services and send events to Cloud Run is unrelated to Eventarc and less efficient.Final Answer:
Create two separate Eventarc triggers, one for Cloud Storage events and one for Pub/Sub events, both targeting the same Cloud Run service -> Option AQuick Check:
Multiple event types = multiple triggers [OK]
- Trying to use one trigger for multiple event types
- Bypassing Eventarc for some events
- Using polling instead of event routing
Ready to prove it?
Pass the test and this pattern moves unknown
