Google PCD: API Design, Integration and Event-Driven Development — Study Guide

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Part of the Google Professional Cloud Developer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Modern application integration on Google Cloud blends well-designed synchronous APIs with resilient asynchronous and event-driven patterns. The goal is to provide clear contracts, strong identity, consistent error handling, and operational controls that keep latency low and availability high even under failure, scaling, or change. This section covers protocol and API choices, gateways and auth, messaging and event routing, background work, orchestration, identity and trust between services, reliability patterns, secure webhooks, and safe schema evolution.

API Design and Management

Choose the right protocol:

REST: Human-friendly, cacheable via HTTP, great for public and partner APIs. Use resource-oriented design, standard methods, ETags, and HATEOAS only when valuable. Trade-off: less precise contracts than protobuf; potential over/under-fetching.
gRPC: Protobuf contracts, bidi streaming, efficient binary transport; strong fit for low-latency, internal service-to-service calls. Trade-off: browser support requires gRPC-Web; observability and compatibility for public clients may be harder.
GraphQL: Flexible querying that reduces round-trips for composite views. Trade-off: complex resolvers, N+1 risks, caching challenges, and access control nuance.

Versioning and pagination:

Prefer additive, backward-compatible changes. Use URI-based major versions (e.g., /v1) and minor revisions via fields and feature flags. Deprecate with clear timelines.
Paginate with stable cursors or nextPageToken to avoid inconsistent pages under churn; avoid offset for large datasets.

Validation and errors:

Use OpenAPI for REST request/response schemas and protobuf validation rules for gRPC.
Adopt a consistent error model: map to canonical HTTP status codes; for gRPC use google.rpc.Status (code, message, details). Include machine-parsable error reasons and a correlation ID. Avoid leaking internals.

API management choices:

API Gateway: Lightweight, managed gateway for OpenAPI/gRPC backends (Cloud Run, Cloud Functions, GKE, Compute Engine). Supports auth, API keys, JWT validation, quotas. Good for serverless and straightforward control planes.
Cloud Endpoints (ESPv2): Deployed with your service; supports OpenAPI or gRPC transcoding, auth, quotas, and metrics. Good when co-locating proxy with workload is preferable.
Apigee: Full lifecycle API management with advanced policies (spike arrest, quotas, mediation, transformation, OAuth providers, monetization, developer portal). Best for complex partner ecosystems and north-south control.

Authentication and quotas:

For end users: OAuth 2.0 or Firebase Authentication; for services: Google-signed ID tokens (OIDC) or OAuth service account tokens (2-legged).
Enforce quotas and spike arrest close to clients (Apigee) and per consumer (API keys or client credentials) to protect backends.

Minimal API Gateway OpenAPI example with Cloud Run backend and OIDC:

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

Asynchronous Messaging and Eventing

Pub/Sub fundamentals:

Topics and subscriptions decouple publishers and consumers. Delivery is at-least-once; duplicates and reordering can occur.
Use acknowledgments and extend ack deadlines when processing is long; apply client flow control to avoid memory pressure.
Ordering: enable message ordering and provide an ordering key to guarantee in-order delivery per key; keep a single active publisher per key when possible.
Dead letters: configure dead-letter topics to contain poison messages and prevent endless retries; monitor and triage.

Create topic, subscription, and DLQ:

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

Consumer reasoning: implement idempotent handlers and deduplication (e.g., by messageId or application-level idempotency key); retry transient errors with backoff; move irrecoverable messages to DLQ and alert.

Eventarc and CloudEvents:

Eventarc routes events from Google Cloud services, custom sources, and Audit Logs to Cloud Run, Cloud Functions, or GKE. Events use the CloudEvents envelope (id, source, type, subject, time).
Filter by attributes (type, subject, location) at the trigger to reduce noise and cost. Use dedicated service accounts for least privilege.

Create an Eventarc trigger for Cloud Storage object finalization:

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

Trade-offs:

Pub/Sub is pull-optimized and resilient for high throughput; Eventarc simplifies routing from producers you don’t control and uses push to your service with standardized metadata.
For strict ordering or hard caps on cost, consider partitioning and rate-limiting at publishers; for very low-latency fanout, tune subscriber concurrency carefully.

Orchestration, Background Work, and Long-Running Processes

Cloud Tasks:

Push-queues for reliable background HTTP calls. Set per-queue dispatch rate and concurrency to protect backends. Configure retries with exponential backoff and max attempts.
Ensure idempotency with a deterministic task name or an Idempotency-Key header and deduplicate server-side. Respond quickly (2xx) and perform heavy work asynchronously if needed.

Create a queue with rate limits and retries:

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows:

Orchestrates multi-step business processes across HTTP and Google Cloud connectors. Model compensating actions (saga pattern) for partial failures; avoid distributed transactions.
Use step-level timeouts and retry policies; persist state across retries so you can resume after outages. Poll long-running operations and cancel on deadline.

Compensation sketch:

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

Operational guidance:

Prefer Cloud Tasks for “fire-and-forget” background HTTP with precise rate control to one service. Use Pub/Sub for fanout and multiple consumers. Use Workflows when you must coordinate several calls with branching logic and compensation.

Identity, Reliability, and Integrations

Service-to-service identity and token propagation:

Cloud Run/Functions/Compute Engine/GKE workloads should use service accounts with least privilege. On GKE, use Workload Identity to avoid node-level credentials.
For Cloud Run to Cloud Run, call with an ID token whose audience matches the target URL. Propagate identity only when the downstream must act on behalf of the caller; otherwise use the callee’s service account.

Fetch an ID token in Cloud Run:

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

Synchronous dependencies and resilience:

Set client timeouts lower than upstream timeouts; budget per hop. Retry only idempotent operations with truncated exponential backoff and jitter. Avoid retry storms by bounding total retry time.
Use circuit breakers to fail fast when an upstream is unhealthy; in GKE/Apigee/Envoy you can configure max pending requests, ejection on failure, and health probes. Provide sensible fallbacks or degrade gracefully.
Map transient errors (429, 408, 500–503) to retriable behavior; treat 4xx (other than 408/429) as non-retriable.

Webhooks and third-party integrations:

Verify inbound requests using an HMAC signature header with shared secret or signed JWT; for higher assurance, use mTLS. Store secrets in Secret Manager and rotate regularly.
Acknowledge quickly; enqueue to Cloud Tasks or publish to Pub/Sub to decouple heavy processing. Rate-limit inbound IPs or keys to protect backends.
Outbound webhooks: include an Idempotency-Key to allow safe retries and verify remote TLS certificates and hostnames.

Schema evolution and compatibility:

REST/JSON: additive fields are safe; never repurpose or change type/meaning of existing fields. Mark deprecated fields and continue serving for a window.
Protobuf/gRPC: never reuse field numbers; use reserved tags; prefer optional fields; defaulting and presence semantics matter for compatibility.
Events: include a dataVersion and keep CloudEvents attributes stable; reserve room for extensions. With Pub/Sub, consider Pub/Sub Schema (Avro/Protobuf) to validate at publish time.
Testing: use consumer-driven contract tests, emulators (Pub/Sub, Datastore/Firestore) or isolated projects, and canary releases. Run integration tests in CI using ephemeral environments and realistic quotas to expose latent failures.

Security and quotas across the stack:

Enforce auth at the edge (API Gateway/Apigee/Endpoints) and at the service. Apply per-consumer quotas and spike arrest. Monitor for 401/403 spikes and 429 rates to tune client backoff and quotas.
Log request IDs across components and propagate tracing headers (Traceparent or X-Cloud-Trace-Context) for end-to-end observability.

Practical Problem Scenario

AcmeRetail is building a click-to-collect service on Google Cloud. A React web app calls a public API to place orders; backend services must reserve inventory, charge payments, and notify stores. The team needs low-latency APIs, reliable background processing, event-driven updates, and safe rollback on partial failures.

Approach:

Expose a public REST API via API Gateway in front of a Cloud Run orders service.

Rationale: REST with JSON is simple for browsers; API Gateway validates JWTs from Firebase Auth, enforces API keys and quotas per client, and terminates at the edge. Cloud Run auto-scales with traffic spikes.

Implement service-to-service calls with gRPC for internal hot paths (orders to inventory, pricing).

Rationale: gRPC reduces serialization overhead and provides strict contracts. Use Workload Identity (GKE) or service accounts (Cloud Run) and OIDC between services. Timeouts are set to 300 ms with two retries and jitter for idempotent reads.

Use Workflows to orchestrate the order saga: charge payment, reserve inventory, create pickup task; compensate on failure.

Rationale: Centralized orchestration manages long-running steps and compensations. If reserve fails, Workflows triggers a refund and returns a 409 to the client.

Publish domain events to Pub/Sub topics orders and inventory for downstream consumers (analytics, store notifications).

Rationale: Fanout without tight coupling. Subscribers implement idempotency keyed by orderId. Subscriptions have dead-letter topics with max-delivery-attempts=10, and alerts fire on DLQ growth.

Trigger store notifications via Eventarc to a Cloud Run notifier service on relevant Cloud Storage and Firestore changes.

Rationale: Eventarc routes only needed events using attribute filters; CloudEvents ensures consistent metadata. The notifier posts to third-party SMS/Email providers using Cloud Tasks to control rate and retries.

Handle payment provider webhooks with a dedicated Cloud Run endpoint fronted by API Gateway, verifying HMAC signatures and using Cloud Tasks for processing.

Rationale: Quick 200 ack reduces provider retries; Tasks ensures retries with backoff. Secrets are stored in Secret Manager; request bodies are validated against OpenAPI schema.

Enforce reliability patterns: circuit breakers at Apigee or Envoy for outbound calls to the payment provider; client timeouts set below provider SLAs; retries with truncated exponential backoff for 429/5xx.

Rationale: Prevents cascading failures and retry storms, respects third-party limits, and turns transient overload into graceful degradation.

Adopt schema evolution controls: Protobuf for internal gRPC with reserved fields; REST responses use additive JSON changes; Pub/Sub uses Protobuf schema validation at publish time.

Rationale: Maintains consumer compatibility. Contract and integration tests run in Cloud Build on each merge; canary deploys validate real traffic safely.

Observe and operate: propagate trace headers between API Gateway and services; export Cloud Logging metrics for error rates and DLQ size; alert on SLO burn and 429/5xx anomalies.