Study guide
4.3 Cache Invalidation, Capacity, and Failover
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
4.3 Cache Invalidation, Capacity, and Failover
Key Takeaways Explain This Topic AI
TTL jitter and bounded cache-fill coordination reduce stampedes.
Memorystore Standard uses asynchronous replication and clients must reconnect after failover.
Cloud Run reaches private caches through a supported VPC egress path.
Last updated: October 2026
Cache Invalidation, TTL Strategies & Mitigating Stampedes
Maintaining cache consistency requires careful key lifecycle management.
Time-to-Live (TTL) Expiration
Always assign a TTL to cached records using Redis expiration commands ( SET key value EX seconds or EXPIRE key seconds ). Without a TTL, abandoned or updated keys consume memory indefinitely until forced out by eviction.
Cache Stampede (Thundering Herd Problem)
A cache stampede occurs when an intensely accessed key expires, causing hundreds of concurrent client threads to simultaneously experience a cache miss and execute identical expensive queries against Cloud SQL, resulting in connection pool exhaustion and database collapse. +--------------------------------------------------------------------------+
- | Cache Stampede Mitigation: Distributed Mutex Locking |
- +--------------------------------------------------------------------------+
- | |
- | 1000 Concurrent Requests arrive for expired key 'catalog:item:42' |
- | | |
- | v |
- | [ Thread 1 ] ---> Acquires Redis Mutex: SET lock:42 NX PX 5000 (Success) |
- | | |
- | +---> Queries Cloud SQL -> Updates Redis 'catalog:item:42' + TTL |
- | | |
- | +---> Releases Mutex Lock |
- | |
- | [ Threads 2-1000 ] -> Mutex Acquisition FAILS |
- | | |
- | +---> Sleep 50ms & Retry Cache OR Return Stale Value Gracefully |
- +--------------------------------------------------------------------------+
- Stampede Defenses
Randomized TTL Jitter: Add random variance to key expiration windows to prevent synchronized mass expiration: Effective TTL = Base TTL + Random ( 0 , Jitter Window ) \text{Effective TTL} = \text{Base TTL} + \text{Random}(0, \text{Jitter Window}) Effective TTL = Base TTL + Random ( 0 , Jitter Window )
Cache-Fill Coordination with Expiring Locks: When a cache miss occurs, the worker attempts to acquire an atomic distributed lock in Redis ( SET lock:product:101 random_token NX PX 5000 ). Only a successful lock holder should refill the entry; release with a compare-and-delete check of the unique token so an expired holder cannot delete its successor's lock. Bound retries and tolerate duplicate cache fills. Such a lock is not a durable transaction or payment deduplication record.
Redis Maxmemory Eviction Policies
When a Memorystore for Redis instance reaches 100% of its provisioned memory capacity ( maxmemory ), its configured eviction policy dictates whether incoming writes succeed or fail.
Eviction Policy Mechanics & Use Case
allkeys-lru Recommended for pure caches. Evicts the Least Recently Used (LRU) keys out of the entire keyspace, regardless of whether a TTL is set. Provides eviction under memory pressure; writes can still fail for other resource or operational reasons.
volatile-lru Evicts the Least Recently Used keys only among keys that have an explicit expiration (TTL) configured. Keys without TTL are preserved. Ideal when mixing ephemeral cache with persistent session data.
allkeys-lfu Evicts the Least Frequently Used (LFU) keys across all keys. Tracks access frequency counters; protects popular items that haven't been accessed recently.
volatile-ttl Evicts keys with the shortest remaining TTL first.
noeviction No automatic eviction. Does not evict any data. When memory is full, all incoming write commands ( SET , HSET , LPUSH ) return out-of-memory (OOM) errors, crashing application write workflows.
Serverless Connectivity: VPC Access Connectors vs. Direct VPC Egress
Memorystore instances are provisioned exclusively with private RFC 1918 IP addresses inside your Virtual Private Cloud (VPC). They have no public IP addresses and cannot be reached over the public internet.
Because serverless runtimes (Cloud Run, Cloud Functions, App Engine standard) operate inside Google-managed multitenant networks, they cannot communicate with private VPC IPs out of the box. +--------------------------------------------------------------------------+
- | Serverless to Private Memorystore Networking |
- +--------------------------------------------------------------------------+
- | |
- | [ Cloud Run Service (Serverless Compute) ] |
- | | |
- | +--- Option A: Direct VPC Egress (Recommended - High Throughput) |
- | | Attaches container network interface directly |
- | | |
- | +--- Option B: Serverless VPC Access Connector |
- | Routes packets via dedicated /28 connector VMs |
- | | |
- | v |
- | [ Customer VPC Network: 10.0.0.0/16 ] |
- | | |
- | v |
- | [ Memorystore for Redis Standard Tier HA (Private IP: 10.0.0.4:6379) ] |
- +--------------------------------------------------------------------------+
- Option A: Direct VPC Egress (Recommended for Modern Cloud Run)
Architecture: Cloud Run allocates network interfaces directly into your VPC subnet without requiring intermediary connector VMs.
Benefits: Delivers lower latency, higher throughput (within Cloud Run instance and network throughput limits), and zero additional VM compute charges.
- Configuration CLI: gcloud run services update catalog-service \
- -network=custom-vpc \
- -subnet=serverless-subnet \
- -vpc-egress=private-ranges-only
- Option B: Serverless VPC Access Connector
Architecture: Provisions managed e2-micro or f1-micro proxy VMs within a dedicated, unallocated /28 subnet in your VPC.
Throughput Limits: Scalable between 2 and 10 connector instances; total bandwidth is constrained by connector VM capacity.
High Availability, Replication & Automated Failover
Google Cloud offers two tiers for Memorystore for Redis:
Basic Tier
Topology: Single standalone Redis node in a single zone.
High Availability: None. No replication, no SLA. If the underlying host fails, memory is reinitialized and data is completely wiped.
Standard Tier (High Availability)
Topology: Provisions a primary node in one zone and a cross-zone standby replica in a second zone within the same region.
Replication: Asynchronous replication keeps the standby replica synchronized with the primary.
Automated Failover: If the primary node fails or undergoes maintenance, Google Cloud detects the health probe failure and promotes the standby replica to primary after failure detection; failover commonly takes around 30 seconds and is not a fixed deadline.
IP Endpoint Preservation: The connection IP address and port ( 10.x.x.x:6379 ) automatically repoint to the promoted node. Application containers do not need to re-resolve DNS or alter connection strings.
Official references checked October 18, 2026: Google Cloud 1 .