Prepare and test your skills
Prepare and test your skills
Connectivity, security, and performance optimization for managed caches is the practice of connecting applications over private network paths, restricting who can manage data, and using memory metrics to scale before latency drops. In Google Cloud, Memorystore for Redis (opens in a new tab) , Memorystore for Redis Cluster (opens in a new tab), and Memorystore for Valkey (opens in a new tab) provide fully managed in-memory stores that serve hot data in sub-millisecond time instead of forcing every read to go to a disk-based backend store. Application traffic flows from clients in an authorized Virtual Private Cloud (VPC) to the cache private endpoint, and monitoring metrics flow from the cache back to operators for tuning hit ratio and memory pressure.
Secure private connectivity means the cache has no public IP and is reachable only from inside its authorized VPC. Memorystore for Redis protects instances from the internet by assigning private IPs and limiting access to applications running on the same authorized VPC as the Redis instance. That VPC boundary creates a trust boundary with application servers and the cache on the inside and the public internet on the outside. Because applications connect to a single private endpoint, management stays simple while network exposure stays closed.
Identity and encryption controls in Memorystore add authentication and in-transit protection on top of the private network boundary. Identity and Access Management (IAM) provides role-based access control (RBAC) that determines who can manage and access the Redis instance, so ownership of data-plane access and control-plane administration can be separated. In-transit encryption, including Transport Layer Security (TLS), protects cache traffic as it flows from the application VPC to the Memorystore endpoint. Standard Tier high-availability instances extend this model across zones with replicas and a 99.9% availability service-level agreement (SLA).
Monitoring cache health means watching how often the cache answers reads and how full system memory is becoming. The cache-hit ratio shows what percentage of key lookups are successfully returned from memory, and a higher ratio generally means fewer slow backend reads. Memorystore exposes memory and key metrics through Cloud Monitoring that together explain performance and eviction behavior.
/cluster/memory/maximum_utilization or /instance/memory/maximum_utilization): highest memory use across shards or an instance, used to decide when a Redis Cluster or Valkey instance needs more capacity.maxmemory-gb, eviction policy, or size, then check it again after the change.volatile-* policy means there is nothing to evict when memory fills.-OOM command not allowed under OOM prevention errors.Memory pressure management in Memorystore controls what happens when data approaches the configured memory limit. Maxmemory (maxmemory-gb) is the Redis limit where the eviction policy takes effect, and by default Memorystore for Redis sets maxmemory-gb to the provisioned instance capacity. Memorystore for Redis Cluster and Memorystore for Valkey use the volatile-lru eviction policy, which evicts least-recently-used keys that have an EXPIRE TTL set. If applications do not set TTLs under a volatile-* policy, the cache has no eligible keys to evict and can enter an out-of-memory condition when data reaches the limit.
When an instance shows memory pressure or out-of-memory errors, resolve the condition in an order that restores headroom first and then fixes the root cause:
volatile-lru policy has candidates to evict.activedefrag on Redis 4.0 and higher instances to reduce fragmentation-driven pressure.maxmemory-gb when system ratio exceeds 80%: create overhead for spikes from export, scaling, maintenance, or failover rather than letting system memory crash the instance.Exam tip: If system memory usage ratio exceeds 80%, lower maxmemory-gb to add overhead; scaling up alone does not fix fragmentation or missing TTLs.
Scaling for performance and availability means adding memory, CPU headroom, and replicas before hot keys or high writes cause throttling. Memorystore for Redis scales up to 300 GB per instance and can spread read queries across five read replicas using a read endpoint, so read traffic flows from applications to replicas instead of overloading the primary. Memorystore for Redis Cluster supports up to five replicas per shard, which preserves CPU capacity if a zonal outage removes nodes in one zone. Operators should monitor main-thread CPU with /cluster/cpu/maximum_utilization and keep enough CPU overhead to absorb traffic shifted from a lost zone.
Memory scaling thresholds depend on write load, because heavy writes need more free memory for replication overhead. The following thresholds use /cluster/memory/maximum_utilization to decide when to scale a Redis Cluster.
| Workload type | Utilization threshold | Scaling decision |
|---|---|---|
| Normal write load | Approaches 100% with expected growth | Scale up cluster size to make room for new data |
| Moderately high write load | Reaches 85% or higher | Scale up cluster size to avoid performance issues |
| Very high write load | Reaches 65% or higher | Scale up cluster size immediately to avoid performance issues |
Scaling down requires extra care to protect hit ratio and durability. Perform shard scaling during low-write periods, and for workloads that must not lose keys, provision enough shards for at least 1.5 times the data shown by /cluster/memory/total_used_memory. If the use case relies on eviction, a smaller size will lower the cache-hit ratio through expected evictions rather than data loss. For maintenance and export operations, keep system memory usage ratio at 50% or less so background copies and updates have room to complete.
Selection of caching engines and service tiers is the decision of which managed in-memory store to use and what level of availability, replication, and persistence to provision. Memorystore for Redis (opens in a new tab) is a fully managed service powered by the Redis in-memory data store that provides sub-millisecond data access for application caches. It is Redis protocol compatible, so existing tools, client libraries, and open source Redis applications move without code changes, while provisioning, replication, failover, and monitoring are automated. The choice depends on how much data loss, downtime, and read load the application can tolerate.
Caching engine selection compares Memorystore for Memcached (opens in a new tab) and Memorystore for Redis for fast, real-time processing. Memorystore for Redis supports rich data structures and use cases beyond simple key-value caching, including Sorted Set for gaming leaderboards with unique elements, hash for frequently accessed player profiles, and intermediate storage for stream processing with Dataflow. Memorystore for Memcached uses a node-based model where clients discover cache nodes through the Auto Discovery service, which enables programmatic discovery of nodes and is compatible with most clients that support AWS ElastiCache auto discovery.
Memorystore for Redis is a good fit when the workload needs low-latency access to heavily accessed data, real-time structures, replication, and snapshot persistence:
Memcached client libraries across all languages are supported, and both engines expose metrics and dashboards in the Google Cloud console through integration with Cloud Monitoring (opens in a new tab).
Redis service tiers define whether the instance runs standalone or as a replicated, highly available system. Basic Tier is a standalone Redis instance for cache capacity without replica failover. Standard Tier is a high-availability Redis instance, available up to 300 GB, with replicas distributed across zones, automatic failover, and a 99.9% availability SLA.
| Tier | Topology | Replication and availability |
|---|---|---|
| Basic Tier | Standalone Redis instance | Single instance with no cross-zone replica set described; scale up in place as needs change |
| Standard Tier | Highly available instance up to 300 GB | Up to five replicas replicated across zones with automated failover, 99.9% availability SLA, and read scaling across five read replicas through the read endpoint |
Start with the lowest tier and smallest size, then grow the instance as application needs change. Scaling up is designed to meet latency and throughput targets with minimal impact to application availability. Choose Standard Tier when the cache must survive zone or node failure and serve higher read throughput.
Exam tip: Choose Standard Tier when you need cross-zone replicas, automatic failover, and the 99.9% availability SLA; Basic Tier is a standalone instance without that replica set.
Replication and high availability in Memorystore for Redis depend on the Standard Tier replica set and automated failover. Data flows from the primary instance to its replicas across zones, and client traffic flows to the primary through the single endpoint while read queries can flow to the five read replicas through the read endpoint. If the primary fails, the service promotes a replica through automatic failover, with failure detection and patching handled as fully managed operations. The trust boundary sits at the private network, where Redis instances are protected from the internet using private IPs and are further secured using Identity and Access Management role-based access control and in-transit encryption.
Persistence in Memorystore for Redis Cluster protects data by saving snapshots to durable storage for automated recovery when failover is not possible. Nodes with replicas prioritize data recovery from the replica first, and only when primary and replica fail simultaneously does the node recover from the most recent snapshot. Recovery from snapshots accepts a small degree of data staleness, and snapshots add no additional cost to instance billing. Snapshot scheduling is controlled by a start time and an interval, with allowed intervals of 1h, 6h, 12h, and 24h evaluated in the UTC time zone.
Only the most recent successful snapshot is retained, snapshots are used only for automated recovery and are not available for manual restores, and shards added by horizontal scale-up are not included until the next scheduled time. To pause snapshots, set the start time to the future and the last snapshot is retained for recovery; to resume, adjust the schedule to the next desired snapshot time. You must choose either RDB or Append-Only File (AOF) persistence because both cannot be enabled at the same time, and for best availability combine persistence with a highly available instance rather than relying on snapshots alone.
Implementation of caching patterns and data lifecycle is the practice of deciding when data enters memory, how writes flow between cache and persistent storage, and when data expires or is evicted. In Google Cloud, Memorystore for Redis (opens in a new tab) and Memorystore for Redis Cluster (opens in a new tab) provide managed external caches in front of persistent stores, while the Bigtable in-memory tier (opens in a new tab) provides an integrated memory tier inside Bigtable nodes through a single API. Together these options reduce read latency, lower database and disk load, and require explicit Time-to-Live (TTL) and eviction choices to keep data fresh and memory healthy.
Caching patterns define the request and data flow between the application, the in-memory tier, and persistent storage. Read-through with lazy loading loads data into memory only when it is requested, write-through writes data to cache and persistent storage together, and write-back writes to cache first and updates storage later. The application uses frequent-data caching, API-response caching, and in-memory storage in RAM to avoid repeated database queries and slow disk operations. In the Bigtable in-memory tier, read-through behavior is provided by hybrid storage nodes that add a memory tier to Bigtable compute and storage.
A row enters the memory tier when an application reads it through an app profile configured for the in-memory tier, and data flows from the local solid-state drive (SSD) tier to the memory tier on that read. A later write operation from any app profile updates the memory tier if that row is already present, so cached rows stay consistent without preloading the full dataset.
| Pattern | Write flow | Read behavior | Choose when |
|---|---|---|---|
| Read-through / lazy loading | Write flows to persistent storage and updates memory only if the row is already cached | First read misses memory and loads data from SSD tier to memory; later reads hit memory | Reads are skewed to a subset of rows and preloading all data would waste memory |
| Write-through | Write flows synchronously to cache and persistent store | Later reads are more likely to hit cache, so fewer energy-intensive reads reach storage | Freshness matters more than write speed and read hit ratio must stay high |
| Write-back / write-behind | Write flows to cache first, then flows asynchronously from cache to database | Reads hit fresh cached writes immediately | Application is write-heavy and must reduce immediate write load on slower databases |
The pattern choice controls freshness, latency, and backend load because the write path determines when storage and cache converge. Read-through keeps memory lean by caching only requested rows, write-through increases the likelihood of cache hits at the cost of synchronous writes, and write-back improves write performance at the cost of a window where cache holds newer data than storage.
TTL settings are expiration timers that invalidate cached entries after a configured lifetime to maintain freshness and free memory. In Memorystore for Redis Cluster, the application sets expiration with commands such as EXPIRE, and in the Bigtable in-memory tier, TTL invalidation combines with Least Recently Used (LRU) eviction to maximize hit ratio. Without TTLs on expirable keys, volatile eviction policies have nothing eligible to remove when memory fills. Freshness in the in-memory tier depends on three related behaviors that connect reads, writes, and missing data.
A write to a row eventually updates that row in every memory tier where it is present, following Bigtable eventual consistency across clusters, while each cluster independently loads only the row keys its own read traffic requests. Negative caching remembers for a period that a resource is missing, so repeated requests for absent rows do not overload the backend. Only the latest timestamped versions of a row reside in memory, and requests for earlier historical cells bypass the memory tier and are served from persistent storage.
Exam tip: Memorystore for Redis Cluster uses volatile-lru, which evicts only keys with an expiration, so an out-of-memory condition can occur at the maxmemory-gb limit when no TTLs are set.
Eviction policies determine which cached entries are removed when memory reaches its configured limit so new writes can proceed. Memorystore for Redis Cluster uses the volatile-lru eviction policy, which removes the least recently used keys among keys with expirations, and the Bigtable in-memory tier uses LRU eviction at the row level. Because eviction only reclaims eligible entries, TTL configuration directly controls whether eviction can relieve pressure or whether memory keeps growing. Memory utilization is governed by the maxmemory-gb limit (opens in a new tab), the cache-hit ratio, and system overhead from fragmentation and intensive operations.
In Memorystore for Redis, maxmemory-gb sets the memory limit where the eviction policy takes effect and defaults to instance capacity at creation, but the limit may need to be lowered to leave overhead for spikes. Cache-hit ratio measures the percentage of key lookups returned from memory, so the ratio should be recorded before changing maxmemory-gb, eviction policy, or instance size and checked again afterward to judge the impact. This before-and-after comparison shows whether a tuning change helped efficiency or reduced the working set that fits in memory.
Monitoring memory health means tracking how full the cache is relative to safe thresholds for the current write load. Write load is the volume and speed at which the application adds or updates keys, and higher write load needs more headroom because replication, slot migration, and fragmentation consume extra system memory. Scaling shards during periods of low writes avoids adding migration overhead on top of heavy writes, and scaling down a cache that uses evictions will lower hit ratio because fewer entries fit.
/cluster/memory/maximum_utilization signals shard pressure: normal write loads perform well at 100% or lower, moderately high write loads can show issues at 85% or higher, and very high write loads can show issues at 65% or higher.volatile-* policy means nothing can be evicted, while many expired keys with continued pressure means maxmemory-gb is still too high.When pressure or blocked writes occur, the cache lifecycle follows an ordered recovery sequence that restores eligible evictions before adding capacity:
volatile-lru has candidates to evict.activedefrag on Redis 4.0 and higher to reclaim fragmented memory.maxmemory-gb before export, scaling, version upgrades, or maintenance that temporarily needs extra system memory.This sequence preserves availability because it first makes eviction possible, then creates overhead, and only then grows or shrinks provisioned memory. For persistent working sets, the target shard count must hold 1.5 times current data size, while eviction-based caches can scale smaller with the explicit tradeoff that hit ratio will fall as capacity shrinks.
volatile-lru eviction policy, which evicts only least-recently-used keys with a TTL, so missing TTLs can cause out-of-memory errors at the maxmemory-gb limit.maxmemory-gb, while Redis Cluster scaling thresholds are 100% for normal writes, 85% for moderately high writes, and 65% for very high writes.Basic Tier is a standalone Redis instance for cache capacity without replica failover, while Standard Tier is a highly available instance up to 300 GB with replicas distributed across zones, automatic failover, and a 99.9% availability service-level agreement (SLA). Standard Tier can spread read queries across five read replicas using a read endpoint, so choose Standard Tier when the cache must survive zone or node failure and serve higher read throughput.
The volatile-lru policy evicts only least-recently-used keys that have an expiration set with a Time-to-Live (TTL), so if applications do not set TTLs there are no eligible keys to evict when data reaches the maxmemory-gb limit. That missing TTL coverage can cause an out-of-memory condition with blocked writes at the limit.
Lower maxmemory-gb to create overhead for spikes from export, scaling, maintenance, or failover rather than letting system memory crash the instance. Scaling up alone does not fix fragmentation or missing TTLs, so also ensure expirable keys have Time-to-Live (TTL) values, consider active defragmentation on Redis 4.0 and higher, and review system memory usage ratio, cache-hit ratio, and expirable keys.
Last updated