Study guide
3.1 Schema Evolution and gRPC Routing
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
3.1 Schema Evolution and gRPC Routing
Key Takeaways Explain This Topic AI
Reserve removed Protobuf tags and names to prevent accidental reuse.
One long-lived gRPC connection can hotspot a connection-balanced backend.
Cloud Run gRPC containers accept cleartext HTTP/2 behind platform TLS termination; configure end-to-end HTTP/2.
Last updated: October 2026
Schema Evolution and Compatibility Rules
In microservice architectures, different services are deployed independently. A newer service version may send data to an older service version (forward compatibility), or an older client may call a newer service version (backward compatibility).
To preserve backward and forward compatibility without breaking production services, you must follow strict Protobuf schema evolution rules:
Rule 1: Never Change the Numeric Tag of an Existing Field
Field names are completely stripped during compilation and serialization. The binary payload on the wire contains only the numeric tag and the encoded value. If you change a field tag from 2 to 5 , an older client sending tag 2 will result in the receiving service failing to parse the field or populating the wrong data.
Rule 2: Never Remove a Field Without Reserving Its Tag and Name
If you deprecate or delete a field (e.g., discount_code with tag 5 ), you must explicitly mark both the tag number and the field name as reserved : reserved 5;
reserved "discount_code";
Exam Trap: If a developer deletes field 5 without reserving it, another developer may subsequently assign tag 5 to a new field (e.g., loyalty_points ). When an older client sends a request containing the legacy discount_code string on tag 5 , the new server will attempt to parse that string as loyalty_points (or decode unexpected bytes), leading to silent data corruption or deserialization errors. Declaring tags and names as reserved causes the Protobuf compiler ( protoc ) to fail the build if anyone attempts to reuse them.
Rule 3: Unknown Fields Are Preserved
In proto3, unknown fields are preserved by binary parsing/serialization in supporting proto3 implementations. Converting through JSON or copying only known fields can lose them. This allows intermediary microservices to route messages without dropping newly added fields.
Rule 4: Renaming Fields Does Not Break the Wire Protocol
Because field names are not transmitted over the wire, renaming a field in the .proto file (e.g., changing order_id to purchase_id while preserving tag 1 ) preserves binary field identity. It can still break generated source bindings or Protobuf JSON consumers, because those interfaces expose names.
The Four gRPC Communication Patterns 1. Unary RPC:
- Client -------- Request (Single Message) --------> Server
- Client <------- Response (Single Message) <------- Server
2. Server Streaming RPC:
- Client -------- Request (Single Message) --------> Server
- Client <======= Stream of Response Messages ====== Server
3. Client Streaming RPC:
- Client ======= Stream of Request Messages ======> Server
- Client <------- Response (Single Message) <------- Server
4. Bidirectional Streaming RPC:
- Client ======= Stream of Request Messages ======> Server
- Client <====== Stream of Response Messages ====== Server
Unary RPC: Standard request-response pattern. Ideal for CRUD operations, authentication checks, and database lookups.
Server Streaming RPC: The client sends a single request and receives a sequence of responses over a persistent stream. Ideal for real-time order status tracking, stock ticker feeds, and log streaming.
Client Streaming RPC: The client streams a sequence of messages to the server and awaits a single summary response. Ideal for telemetry ingestion, IoT sensor batch uploads, and multi-part file transfers.
Bidirectional Streaming RPC: Both client and server send a stream of messages concurrently using two independent read/write channels over a single multiplexed HTTP/2 connection. Ideal for real-time collaboration tools, multiplayer gaming, and conversational AI synchronization.
The Layer 4 vs. Layer 7 Load Balancing Challenge
A primary architectural trap when deploying gRPC microservices in Kubernetes or behind cloud load balancers is connection-level hotspotting caused by Layer 4 (L4) load balancers.
The Root Cause: HTTP/2 Persistent Multiplexing
In HTTP/1.1, clients open multiple short-lived TCP connections, and L4 balancers distribute these connections evenly across backends. In HTTP/2 and gRPC, however, a client establishes a single long-lived TCP connection to the backend and multiplexes hundreds of concurrent RPC calls across that single connection.
What Happens with Layer 4 Balancing (e.g., Standard Kubernetes ClusterIP Service or TCP Proxy Load Balancer): The L4 load balancer only balances TCP connections . The single TCP connection from the client is routed to one backend pod . All hundreds of subsequent RPC calls travel over that same TCP connection, pinning 100% of the traffic to that single backend pod while remaining backend pods sit at 0% CPU utilization!
The Solution: Layer 7 (Application) Load Balancing: An L7 load balancer (such as Google Cloud Application Load Balancers, an Envoy sidecar proxy, or a service mesh like Cloud Service Mesh / Istio ) understands HTTP/2 frames. It unpacks individual multiplexed RPC requests from the incoming connection and distributes them individually across all available backend pods.
Alternative Solution: Client-Side Load Balancing: The gRPC client library maintains a pool of TCP connections to all healthy backend endpoints (resolved via DNS or xDS control plane) and performs round-robin balancing; pick-first alone does not distribute calls across all endpoints directly in application memory.
- Deploying and Configuring gRPC on Google Cloud
- Deploying gRPC to Cloud Run
Cloud Run fully supports gRPC over HTTP/2 with automatic L7 request-level load balancing across auto-scaled container instances:
Edge TLS Termination: Cloud Run automatically handles TLS certificates and terminates TLS at Google's global edge infrastructure.
Cleartext HTTP/2 ( h2c ) Contract: Because Cloud Run terminates TLS at the edge, traffic forwarded from the edge proxy to your container instance is unencrypted cleartext HTTP/2 ( h2c ) . The gRPC server running inside your container must be configured to accept cleartext HTTP/2 connections on the designated PORT (e.g., using net.Listen("tcp", ":" + port) in Go without TLS credentials).
- Deployment Command: gcloud run deploy order-grpc-service \
- -image=us-central1-docker.pkg.dev/my-project/apps/order-grpc:v1.0 \
- -use-http2 \
- -port=50051 \
- -region=us-central1
- Deploying gRPC on GKE
Configure the chosen GKE Gateway or Ingress controller for its supported HTTP/2 backend protocol. For GKE Ingress, the Service annotation cloud.google.com/app-protocols can select HTTP2 ; Gateway configuration uses its documented Service appProtocol values. These controller-specific mechanisms are not interchangeable.
For east-west traffic between microservices within GKE, deploy Cloud Service Mesh (managed Istio) to provide automated mTLS, L7 request routing, distributed tracing injection, and client-side load balancing across pods without code changes.
Official references checked October 18, 2026: Google Cloud 1 .