4.2 Memorystore and Cache Access Patterns

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.2 Memorystore and Cache Access Patterns

Key Takeaways Explain This Topic AI

Basic/Standard Memorystore for Redis supports RDB persistence, not AOF.

A Redis cache and a separate SQL database do not share an automatic atomic transaction.

Write-behind can lose acknowledged data if the cache fails before durable persistence.

Last updated: October 2026

2.3 Caching Architectures with Memorystore for Redis and Memcached

High-throughput, low-latency cloud applications cannot afford to execute disk-bound relational queries or expensive document scans on every client transaction. Introducing a distributed, in-memory caching tier reduces database load by orders of magnitude while cutting read latencies from double-digit milliseconds down to sub-millisecond durations. Google Cloud provides managed caching through Memorystore for Redis and Memorystore for Memcached .

Architectural Comparison: Memorystore for Redis vs. Memcached

Selecting between Redis and Memcached depends on data structure complexity, persistence requirements, and thread concurrency.

Feature Memorystore for Redis Memorystore for Memcached

Core Architecture Single-threaded execution core (atomic commands). Sub-millisecond latency. Multi-threaded, multi-core architecture capable of scaling across multiple vCPUs.

Data Structures Strings, Hashes, Lists, Sets, Sorted Sets (leaderboards), Bitmaps, HyperLogLogs, Geospatial indexes. Simple key-value store (keys up to 250 bytes; values up to 1 MB).

Persistence Supported via RDB persistence snapshots ; explicit Cloud Storage export is a separate operation ; Basic/Standard Memorystore for Redis does not support AOF. Memorystore for Redis Cluster is a separate product with different persistence options. None. Purely volatile memory. If an instance restarts, all cached data is permanently lost.

High Availability (HA) Standard Tier: Automatic multi-zone failover with an asynchronously replicated standby; around 30 seconds is typical, not a maximum guarantee. None. No automated replication or standby failover. Relies on client-side hashing across nodes.

Read Scaling Supports configured read replicas behind a read endpoint; reads can lag the primary. Scales horizontally by provisioning up to 5 TB across up to 20 independent nodes.

Pub/Sub Messaging Native publish/subscribe channels and Redis Streams. Not supported.

Ideal Workloads Session state, gaming leaderboards, real-time counters, queueing, cached database models. Large-scale read-heavy caching of simple objects, HTML fragments, and stateless lookup tables.

Core Application Caching Patterns

How your application interacts with the cache dictates data freshness, write latency, and failure tolerance. +--------------------------------------------------------------------------+

| Core Application Caching Topologies |
+--------------------------------------------------------------------------+
| |
| 1. Cache-Aside (Lazy Loading): |
| App ---> [ 1. Check Cache ] ---> HIT? Return Data |
| | |
| +-----> MISS? ---> [ 2. Read DB ] ---> [ 3. Populate Cache + TTL ] |
| |
| 2. Write-Through: |
| App ---> [ Write Cache ] === Synchronous Lock ===> [ Write DB ] |
| |
| 3. Write-Behind (Write-Back): |
| App ---> [ Write Cache (Ack Immediately) ] |
| | |
| v (Asynchronous Background Queue) |
| [ Delayed Batch Write to DB ] |
+--------------------------------------------------------------------------+
Cache-Aside (Lazy Loading)

Mechanics: The application code is responsible for managing both the cache and the primary database. On a read request:

The application checks the cache for the requested key.

Cache Hit: The cached payload is deserialized and returned immediately to the client.

Cache Miss: The application queries the primary database (e.g., Cloud SQL or Cloud Spanner).

The application writes the returned record into the cache alongside an explicit Time-To-Live (TTL).

The data is returned to the client.

Advantages: Highly resilient. If the cache crashes or undergoes maintenance, requests degrade gracefully to querying the database directly. Memory is conserved because only actually requested records are populated in cache.

Disadvantages: Initial cache miss penalty on cold starts; potential to serve stale data if backend records are updated out-of-band without cache invalidation.

Write-Through

Mechanics: When updating or inserting records, the application updates durable storage and the cache synchronously according to application logic. Redis and a separate SQL database do not share an automatic atomic transaction; handle partial failure and invalidate inconsistent cache entries. The cache is updated immediately before or simultaneously with the persistent store.

Advantages: Can improve read freshness when all writers follow the protocol; failures and external writers can still produce stale entries.

Disadvantages: Higher write latency because every write must complete against two storage tiers; cache pollution occurs if written data is rarely or never read again.

Write-Behind (Write-Back)

Mechanics: The application writes directly to the in-memory cache, which immediately acknowledges success to the client. An asynchronous background process flushes modified ("dirty") entries to the database in batches.

Advantages: Ultra-low write latency and massive write absorption (ideal for logging, tracking clicks, or IoT telemetry).

Disadvantages: High risk of data loss. If the Redis instance fails before the dirty entries are flushed to Cloud SQL, uncommitted writes are permanently destroyed.

Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .

Worked Cache Correctness Scenario

Suppose an application caches a product price for five minutes while the authoritative price remains in SQL. A cache hit can return an old display price after an administrator changes the database. The checkout transaction must therefore validate the current authoritative price rather than assume the cache is a financial ledger. The TTL bounds ordinary staleness only if the cache entry was correctly refreshed; it does not make the two stores transactional.

When updating a product, commit the durable database change and then invalidate or refresh the cache using a deliberate failure policy. A crash between those actions can leave stale cache data, so choose a bounded TTL and tolerate a refill. During cache failure, fall back only within the database's capacity; unbounded fallback can turn a cache outage into a database outage. A circuit breaker or stale read is appropriate only when the particular response can tolerate that degraded behavior.

Do not treat Redis Pub/Sub as a durable task queue. Subscribers that are absent can miss transient messages, whereas a business event requiring replay and acknowledgment belongs in a durable messaging design. The cache's useful low latency does not replace persistence, consumer receipts or a transaction boundary.