Redefining Event-Driven Architecture on Google Cloud
Source: Dev.to
Choosing Between Eventarc and Direct Pub/Sub
| Feature | Eventarc | Direct Pub/Sub |
|---|---|---|
| Best For | GCP‑native events (GCS, Firestore, Audit Logs) | Custom inter‑service messaging |
| Setup | Managed wrapper, high convenience | Manual configuration, high control |
| Filtering | Built‑in attribute filtering | Fine‑grained policies & custom attributes |
| IAM | Uses eventarc.eventReceiver | Uses pubsub.subscriber |
Pro Tip: Use Eventarc for “plumbing” Google Cloud events. Use Direct Pub/Sub when you need a custom event bus or specific retry/ordering logic.
Delivery Guarantees & Idempotency
- Pub/Sub guarantees at‑least‑once delivery by default.
- Exactly‑once delivery exists as an opt‑in feature, but consumers must still assume duplicates can occur.
- If your handler isn’t idempotent, you risk double‑charging users or corrupting state.
Non‑Negotiable Idempotency Flow
- Extract a unique Idempotency Key (UUID/Hash) from the event.
- Check a fast‑access cache (Memorystore or Firestore) for the key.
- If present, discard the message as a duplicate.
- If absent, process the event and store the key with a TTL.
Cold Starts & Latency
- Cloud Run’s “scale to zero” saves budget but adds 2–8 seconds of latency on the first request.
- Fix: Set
min‑instancesfor latency‑critical paths (incurs cost). - Alternative: Use Cloud Run Jobs for asynchronous batch processing where start‑time overhead is less relevant.
Deployment Considerations
- When deploying Eventarc triggers via Terraform or CLI, filtering rules can take 60–120 seconds to propagate across the Google network.
- Production Fix: Build a “warm‑up” delay into your CI/CD pipeline. Do not trigger integration tests immediately after a successful deployment, or you will see intermittent, false‑positive failures.
Cost at Scale
| Component | Estimate |
|---|---|
| Pub/Sub (ingest + delivery) | 0.286 TiB × $40 × 2 ≈ $23/month |
| Cloud Run (300 M invocations, 1 s, 512 MiB) | $150–$200/month |
| Total | ≈ $175–$225/month |
Assumptions: 10 M events/day (≈ 300 M/month), 1 KB minimum message size, 1 s execution time, 512 MiB RAM.
Monitoring message size and invocation duration keeps costs predictable.
Region Mapping & Egress
- Eventarc triggers for multi‑region services (e.g., Firestore
nam5) are often pinned to specific regions (e.g.,us-central1). - If your Cloud Run service resides elsewhere, you incur cross‑region egress charges and increased latency.
- Always verify the region mapping table in the GCP documentation.
Advanced Eventarc: CEL Transformations
Eventarc Advanced lets you use Common Expression Language (CEL) to transform or redact payloads before they reach the consumer—vital for PII compliance.
// Example: Redacting an email address in‑flight
message.setField("data.email",
re.extract(message.data.email, "(^.).*@(.*)", "\\1***@\\2"));
Reliability Patterns
- Dead‑Letter Topics (DLTs): Every subscription should have a dead‑letter topic.
- Alerting: Monitor the
subscription/dead_letter_message_countmetric; a rising count signals logic bugs or schema mismatches. - Tracing: Use OpenTelemetry to inject Trace IDs into event attributes, allowing you to follow a single request from producer through the bus to consumer logs.
When Not to Use This Architecture
Skip Eventarc + Cloud Run if:
- You require strong consistency and immediate transactions.
- Your end‑to‑end latency requirement is < 100 ms.
- The overhead of debugging distributed traces outweighs the scaling benefits.
In these cases, consider synchronous gRPC/HTTP or Cloud Workflows for structured orchestration.
Conclusion
The combination of Cloud Run and Eventarc remains one of the most robust patterns in 2026. By respecting platform boundaries—accounting for propagation delays, ensuring idempotency, and co‑locating regions—you can build a system that scales effortlessly from zero to millions of events.