Study guide
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc
Google Professional Cloud Architect Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Strategy & Case Study Methodology
1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions
2 Chapter 2: Designing for Business Requirements
2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning
3 Chapter 3: Designing for Technical Requirements & Availability
3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction
4 Chapter 4: Compute Selection & Workload Architecture
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
5 Chapter 5: Storage, Database & Data Warehouse Architecture
5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery
6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing
6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS
7 Chapter 7: Identity, Access & Resource Governance
7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance
8 Chapter 8: Security Architecture, Data Protection & Compliance
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center
9 Chapter 9: DevOps, Automation & Infrastructure as Code
9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators
10 Chapter 10: Site Reliability Engineering & Operations Excellence
10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting
11 Chapter 11: Data Pipelines, Integration & Modernization
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options
12 Chapter 12: Well-Architected Framework & Official Case Study Solutions
12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive
13 Chapter 13: AI, Machine Learning & Generative AI Architecture
13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc
Key Takeaways Explain This Topic AI
Cloud Pub/Sub is a globally distributed, horizontally scalable, multi-tenant asynchronous messaging service delivering at-least-once semantics with sub-100ms latency by default.
Pub/Sub subscriptions encompass Pull, Push (HTTPS webhooks), BigQuery Subscriptions (direct zero-code streaming ingestion), and Cloud Storage Subscriptions (direct Avro/JSON/text archival).
Strict FIFO per-entity message delivery is achieved using Ordering Keys; if an ordered message fails, subsequent messages for that key pause until the failed message is acknowledged or purged.
Message reliability and fault isolation are governed by Dead-Letter Topics (DLQ) with configurable delivery attempts, exponential backoff retry policies, and up to 31 days of message retention with Seek/Replay capabilities.
Pub/Sub Lite provides a lower-cost, partition-based model with provisioned throughput for predictable workloads, while Eventarc delivers unified CloudEvents routing across 130+ Google Cloud sources via Cloud Audit Logs.
Last updated: August 2026
Event-Driven Architectures with Cloud Pub/Sub & Eventarc
Core Principle: Modern enterprise cloud architectures rely on asynchronous, decoupled event distribution to absorb traffic spikes, decouple microservice dependencies, and enable real-time analytical streaming. Google Cloud provides two foundational services for event-driven systems: Cloud Pub/Sub , a globally distributed, horizontally scalable messaging middleware designed for high-throughput streaming and data buffering, and Eventarc , an event routing platform that captures and transforms control-plane and data-plane state changes from across 130+ Google Cloud services into standardized CloudEvents .
Cloud Pub/Sub Architecture & Core Topologies
Cloud Pub/Sub separates message producers ( Publishers ) from message consumers ( Subscribers ) through an asynchronous publish/subscribe pattern. It runs across all Google Cloud regions globally without requiring regional cluster provisioning, sharding, or capacity pre-allocation. +-----------------------------------------------------------------------------------------+
- | CLOUD PUB/SUB ARCHITECTURE MODEL |
- +-----------------------------------------------------------------------------------------+
- | PUBLISHERS | App Engine / Cloud Run / GKE / On-Prem / IoT Devices |
- | | - Publishes messages to a Topic with optional Ordering Keys |
- +--------------------+--------------------------------------------------------------------+
- | TOPICS & ROUTING | Global Topic Namespace (e.g., projects/my-p/topics/telemetry-raw) |
- | | - Automatic horizontal sharding and geo-distributed replication |
- +--------------------+--------------------------------------------------------------------+
- | SUBSCRIPTIONS | 1-to-Many Fanout: Each subscription receives a copy of all msgs |
- | | - Pull / Push / BigQuery Direct / Cloud Storage Direct |
- +--------------------+--------------------------------------------------------------------+
- | CONSUMERS | Dataflow / Cloud Run / BigQuery / GCS / External Microservices |
- +-----------------------------------------------------------------------------------------+
- Core Entities & Message Anatomy
Message: The atomic unit of transmission. It contains a binary payload ( data up to 10 MB), user-defined key-value metadata ( attributes ), a system-generated globally unique identifier ( messageId ), and a server timestamp ( publishTime ).
Topic: A named resource to which publishers send messages. Topics are global resources within a Google Cloud project.
Subscription: A named resource representing a stream of messages from a single specific topic to be delivered to the subscribing application. Multiple subscriptions attached to a single topic receive independent copies of every published message (1-to-many fanout). Multiple workers pulling from a single subscription load-balance message consumption (competing consumers pattern).
Subscription Types & Ingestion Mechanics
Subscription Type Delivery Mechanism Scaling & Management Target Workloads & Protocols
Pull Subscription Subscriber requests messages via HTTP/gRPC Pull or streaming gRPC StreamingPull . Dynamic client-controlled polling; subscriber controls processing rate and batch sizes. High-throughput streaming pipelines (Dataflow, Apache Spark), backend microservices, batch consumers.
Push Subscription Pub/Sub initiates an HTTPS POST request to an exposed webhook URL. Pub/Sub scales webhook delivery automatically; rate-limited by slow HTTP endpoints. Serverless endpoints (Cloud Run, Cloud Functions, App Engine), external SaaS webhooks, lightweight APIs.
BigQuery Subscription Pub/Sub writes directly to a BigQuery table using the BigQuery Storage Write API. Fully managed, zero-code, autoscaling streaming ingestion without compute infrastructure. Direct ELT data ingestion pipelines, analytical event sinks, real-time dashboards without transformation needs.
Cloud Storage Subscription Pub/Sub writes batches of messages directly to Cloud Storage buckets as files. Fully managed, zero-code batching by elapsed time (e.g., 5 min) or byte size (e.g., 50 MB). Raw log archival, compliance backups, data lake ingestion in Avro, JSON, or text format. DIRECT SINK SUBSCRIPTIONS (ZERO-CODE INGESTION)
- +---> [ Pull Subscription ] --------> [ Dataflow Pipeline ]
- |
- +---> [ Push Subscription ] --------> [ Cloud Run Webhook ]
- [ Pub/Sub Topic ]-+
- +---> [ BigQuery Subscription ] ----> [ BigQuery Raw Table ] (Direct Write)
- |
- +---> [ Cloud Storage Sub ] --------> [ GCS Archive Bucket ] (Batch Files)
Tip
Direct BigQuery & Cloud Storage Subscriptions: Prior to the introduction of direct BigQuery and Cloud Storage subscriptions, architects had to deploy intermediate Cloud Functions or Dataflow pipelines solely to stream raw Pub/Sub messages into analytical storage. For pure ingestion pipelines where payload schema mapping is direct, using direct subscriptions eliminates compute operational overhead and reduces pipeline cost by over 60%.
Message Delivery Guarantees, Ordering & Reliability
Understanding Pub/Sub's distributed delivery semantics is critical for designing fault-tolerant distributed systems.
1. Delivery Guarantees & Acknowledgments
At-Least-Once Delivery: By default, Pub/Sub guarantees that every published message is delivered at least once to each subscription. Because Pub/Sub is a distributed system, network timeouts or transient worker failures can cause a message to be redelivered. Consumer applications must be idempotent .
Acknowledgment Deadline ( ackDeadlineSeconds ): When a subscriber receives a message, it has a configurable window (10 to 600 seconds, default 10s) to acknowledge ( ack ) the message. If the subscriber crashes or fails to ack/nack within the deadline, Pub/Sub marks the message as unacknowledged and redelivers it.
Deadline Extension ( modifyAckDeadline ): Pub/Sub client libraries automatically extend the acknowledgment deadline in the background (lease management) while the worker is actively processing the message.
2. Strict Per-Key Ordering (Ordering Keys)
While standard Pub/Sub delivers messages out of order across parallel subscribers to maximize throughput, systems often require strict First-In, First-Out (FIFO) processing for specific entities (e.g., financial ledger transactions per bank account, state updates per IoT device). ORDERING KEYS MECHANICS
Publisher Message Stream:
- [ Msg 1: Key=Account_A ] ---> Sent to Topic
- [ Msg 2: Key=Account_B ] ---> Sent to Topic
- [ Msg 3: Key=Account_A ] ---> Sent to Topic (Must execute AFTER Msg 1)
Pub/Sub Router:
- Key Account_A -> Affinity Partition Worker 1 -> [ Msg 1 ] then [ Msg 3 ]
- Key Account_B -> Affinity Partition Worker 2 -> [ Msg 2 ]
* If Msg 1 processing fails or nacks -> Msg 3 is BLOCKED until Msg 1 succeeds or is purged to DLQ.
Ordering Key Configuration: The publisher assigns an orderingKey string (e.g., account_10492 ) to the message metadata, and the subscription has message ordering enabled.
Sequential Guarantees: Pub/Sub guarantees that messages sharing the same orderingKey are delivered to subscribers strictly in the order they were published.
Head-of-Line Blocking Trap: If an ordered message fails processing or exceeds its ack deadline, Pub/Sub withholds all subsequent messages sharing that identical orderingKey until the failed message is successfully acknowledged, nacked, or redirected to a Dead-Letter Topic. Other ordering keys continue processing concurrently without impact.
3. Dead-Letter Topics (DLQ) & Retry Policies
When malformed payloads ("poison pills") cause continuous consumer crashes, unhandled messages cycle indefinitely through redelivery, consuming resources and stalling ordering keys. DEAD-LETTER TOPIC (DLQ) & EXPONENTIAL BACKOFF
- [ Raw Message ] ---> [ Worker Consumer ] ---> CRASH / NACK
- |
- Retry Attempt 1 (Min Backoff: 10s)
- |
- Retry Attempt 2 (Backoff: 20s)
- |
- Retry Attempt N (Exceeds MaxDeliveryAttempts = 5)
- |
- v
- [ Dead-Letter Topic (DLQ) ] ---> Alert / Debug Storage
Dead-Letter Topics: Configured on a subscription with a maxDeliveryAttempts threshold (between 5 and 100). When a message fails delivery more than N N N times, Pub/Sub automatically routes the message to a designated Dead-Letter Topic and acknowledges it on the primary subscription.
Retry Policies:
Immediate Retry: Pub/Sub attempts redelivery immediately upon ack deadline expiration or explicit nack.
Exponential Backoff: Configured with a minimumBackoff (e.g., 10s) and maximumBackoff (e.g., 600s). Pub/Sub doubles the delay between successive delivery attempts, preventing downstream database thundering herd problems during outages.
4. Message Retention & Seek / Replay
Retention Limits: Pub/Sub retains unacknowledged messages on subscriptions for up to 31 days (default 7 days). Topics can also be configured with message retention independent of subscriptions.
Retaining Acknowledged Messages: Subscriptions can be configured to retain acknowledged messages within the retention window.
Seek Operation: Allows operators to rewind a subscription's message consumption cursor back to a specific timestamp in the past or to a named snapshot. This enables:
Replaying historical events after deploying a bug fix in consumer code.
Backfilling a newly created analytics pipeline with past events.
Purging accumulated backlogs instantly by seeking to the current timestamp.
Pub/Sub Standard vs. Pub/Sub Lite
Google Cloud provides two distinct tiers of the Pub/Sub messaging service tailored to different architectural and economic requirements.
Architectural Dimension Cloud Pub/Sub (Standard) Cloud Pub/Sub Lite
Architecture & Scope Global service; automatic cross-region replication; zero zone configuration. Zonal or Regional service; partition-based architecture (similar to Apache Kafka).
Scaling Model Fully serverless; instantaneous automated horizontal autoscaling. Pre-provisioned capacity per partition (MiB/s publish, MiB/s subscribe, GiB storage).
Throughput & Capacity Virtually unlimited; no manual shard management. Manual partition sizing (1 partition = 4 MiB/s publish, 8 MiB/s subscribe).
Cost Structure Pay per volume published/subscribed ($40/TB ingested + egress). Provisioned throughput and storage pricing (up to 80% lower cost for steady-state workloads).
Message Retention Up to 31 days per topic/subscription. Up to 30 days per partition (capped by provisioned GiB storage).
Availability SLA 99.95% (Regional/Global). 99.9% (Regional Lite) / 99.5% (Zonal Lite).
Ideal Workloads Unpredictable, spiky traffic; multi-region ingestion; serverless integration. High-volume, predictable log aggregation, Kafka replacement, cost-sensitive telemetry.
Eventarc: Unified CloudEvents Routing
While Pub/Sub is engineered for high-volume data streaming, Eventarc is engineered for event-driven orchestration and state change notifications across Google Cloud infrastructure. +-----------------------------------------------------------------------------------------+
- | EVENTARC EVENT ROUTING MODEL |
- +-----------------------------------------------------------------------------------------+
- | EVENT SOURCES (130+ Google Cloud Services) |
- | 1. Direct Events: Cloud Storage (object finalize), Pub/Sub, Firebase |
- | 2. Cloud Audit Logs: Any GCP API mutation (Compute VM created, BigQuery job, IAM edit) |
- | 3. Custom Events: External applications via Eventarc Publishing API |
- +-----------------------------------------------------------------------------------------+
- | | |
- | v |
- | EVENTARC ROUTING ENGINE (Filters on attributes: type, serviceName, methodName) |
- | - Standardizes all payloads into CloudEvents v1.0 specification |
- +-----------------------------------------------------------------------------------------+
- | | |
- | v |
- | EVENT DESTINATIONS |
- | - Cloud Run Services / Cloud Functions (2nd Gen) / GKE Services / Cloud Workflows |
- +-----------------------------------------------------------------------------------------+
- Key Eventarc Architectural Capabilities
CloudEvents Standard Format: Eventarc encapsulates all events in the CNCF CloudEvents v1.0 open standard specification, providing consistent metadata attributes ( id , source , type , time , datacontenttype , and data ). This prevents proprietary vendor lock-in.
Cloud Audit Log Integration: Eventarc can capture events from any Google Cloud service that writes to Cloud Audit Logs (over 130+ GCP services). For example, creating a new Compute Engine VM, altering an IAM policy, or completing a Spanner backup can trigger an automated remediation workflow without polling or custom application code.
Eventarc Triggers & Filtering: Triggers define declarative routing rules matching specific attributes (e.g., type: google.cloud.audit.log.v1.written , serviceName: storage.googleapis.com , methodName: storage.objects.create ).
Secure Delivery: Eventarc invokes destinations using authenticated HTTPS calls, automatically managing IAM service account OIDC identity tokens.
Pub/Sub vs. Eventarc Decision Matrix
Decision Factor Cloud Pub/Sub Eventarc
Primary Architectural Role High-throughput streaming data buffer & messaging middleware. Event-driven control-plane and infrastructure automation router.
Data Volume & Throughput Millions of messages/sec; gigabytes of streaming payload. Thousands of discrete state-change events/sec.
Payload Structure Arbitrary binary, JSON, or Avro payload. Standardized CloudEvents JSON format.
Event Sources Application code, IoT edge, custom publisher SDKs. 130+ GCP services via Audit Logs, direct GCP events, custom apps.
Target Destinations Pull consumers, Push webhooks, BigQuery tables, GCS buckets. Cloud Run, Cloud Functions (2nd gen), GKE, Workflows.
- Concrete Architectural Scenario: Real-Time E-Commerce Ledger & Fraud Detection
- Scenario Profile
Client: Global E-Commerce Retailer handling 50,000 transactions per second during flash sales.
Requirements:
Financial ledger updates for each user account must process strictly in chronological order without race conditions.
Malformed transactions must not block legitimate customer orders.
Raw transactions must stream into BigQuery for real-time analytics with zero custom ETL compute infrastructure.
Any administrative modification to payment IAM service accounts must immediately trigger an automated security audit function. [ Web/Mobile Checkout ] ---> (Publishes with OrderingKey=Account_ID) ---> [ Pub/Sub Topic: Orders ]
- |
- +------------------------------------------------+----------------+
- | | |
- v v v
- [ Subscription: Ledger-Worker ] [ Subscription: Direct BQ ] [ Subscription: GCS ]
- Message Ordering Enabled - Direct BigQuery Stream - Avro Raw Archive
- DLQ Topic: orders-dlq (maxAttempts=5) - Zero Compute Footprint - Coldline Tier
- Exponential Backoff: 5s to 300s |
- | v
- v [ BigQuery Real-Time Table ]
- [ Cloud Run Ledger Worker ]
- [ IAM Admin Change ] ---> [ Cloud Audit Log ] ---> [ Eventarc Trigger ] ---> [ Cloud Run Security Auditor ]
- Architecture Blueprint
Sequential Order Processing: The checkout application publishes order messages with orderingKey = user_account_id . The Ledger-Worker subscription has message ordering enabled, guaranteeing strict chronological processing per customer account.
Fault Isolation: The subscription configures a Dead-Letter Topic ( orders-dlq ) with maxDeliveryAttempts = 5 . If an unparseable order payload fails 5 times, it is automatically routed to the DLQ, unblocking the ordering key for subsequent customer transactions.
Serverless Analytical Ingestion: A BigQuery Subscription streams orders directly into the analytics warehouse with zero intermediate Cloud Functions or Dataflow worker costs.
Security Governance: An Eventarc Trigger listens for google.cloud.audit.log.v1.written events on the iam.googleapis.com service, routing administrative changes immediately to a Cloud Run Security Auditor service.
Important
Exam Watch:
If an exam question asks for strict message ordering per customer/entity , select Pub/Sub Ordering Keys . Remember: ordering is per-key, not global across the entire topic.
If poison-pill messages are causing pipeline crashes or head-of-line blocking on ordered subscriptions, configure a Dead-Letter Topic (DLQ) with a retry policy.
If an exam scenario requires reacting to GCP service lifecycle events (such as Cloud Storage uploads, BigQuery table creation, or IAM modifications) across 130+ Google Cloud services using standardized formats, Eventarc is the correct architectural choice.