This chapter covers Cloud Memorystore for Redis and Memcached, Google Cloud's managed in-memory caching services. You will learn the architecture, key differences between Redis and Memcached, configuration options, and best practices for high-availability and performance. On the ACE exam, this topic appears in roughly 5–8% of questions, primarily in the context of application performance optimization and data tiering. Mastery of Memorystore is essential for designing scalable, low-latency applications on Google Cloud.
Jump to a section
Imagine a busy office where employees frequently need access to a large reference book in a locked cabinet. Every time someone needs a piece of data—say, a customer's phone number—they walk to the cabinet, unlock it, search the book, copy the number, and return to their desk. This takes 30 seconds per lookup. Now imagine a large whiteboard placed in the center of the office. An employee who looks up a number writes it on the whiteboard in large letters. The next employee who needs the same number simply glances at the whiteboard (1 second) instead of walking to the cabinet. The whiteboard has limited space, so when it fills up, the oldest or least-used entries are erased to make room for new ones. The office manager decides how much space the whiteboard has and can set rules about which entries stay longer. If the whiteboard is too small, many lookups still go to the cabinet, defeating the purpose. If it's too large, it wastes wall space. This is exactly how Cloud Memorystore works: the whiteboard is the Redis or Memcached instance, the reference book is the persistent database, and the lookup time savings is the latency reduction. The manager's decisions map to instance size, eviction policies, and TTL (time-to-live) settings.
What is Cloud Memorystore?
Cloud Memorystore is a fully managed in-memory data store service for Redis and Memcached. It provides sub-millisecond latency by keeping data in RAM, offloading read-heavy workloads from backend databases. The service handles provisioning, replication, failover, patching, and monitoring, freeing you from operational overhead.
Why In-Memory Caching?
Traditional databases store data on disk, which has higher latency (1–10 ms) compared to RAM (microseconds). For applications that need to serve the same data repeatedly—like session stores, leaderboards, or real-time analytics—caching reduces latency and database load. Memorystore is ideal for these use cases.
Redis vs. Memcached: Core Differences
Data Structures: Redis supports strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, and streams. Memcached only supports simple key-value strings.
Persistence: Redis can persist data to disk (RDB snapshots, AOF logs). Memcached is purely in-memory; data is lost on restart.
Replication: Redis supports master-replica replication for high availability. Memcached does not support replication natively.
Eviction Policies: Redis has multiple eviction policies (e.g., allkeys-lru, volatile-ttl). Memcached uses LRU only.
Use Cases: Redis for complex data types and persistence; Memcached for simple caching with maximum throughput.
Memorystore Architecture
A Memorystore instance runs on a Compute Engine VM managed by Google. You choose a tier: Basic (single node, no replication) or Standard (with a read replica and automatic failover). The instance is provisioned with a specified amount of memory (1 GB to 300 GB for Redis, up to 64 GB for Memcached). You connect via a private IP address within your VPC network. The service uses gRPC for management and standard Redis/Memcached protocols for data operations.
Creating a Memorystore Instance
You can create an instance using the Console, gcloud CLI, or Terraform. Example gcloud command for a Standard tier Redis instance:
gcloud redis instances create my-redis \
--size=5 \
--region=us-central1 \
--redis-version=redis_7_0 \
--tier=standard \
--network=defaultThis creates a 5 GB Redis instance in us-central1 with a replica. The instance gets a private IP address like 10.0.0.3.
Connecting to Memorystore
Applications connect using the Redis client library (e.g., redis-py, Jedis) or Memcached client. You must configure the client to use the instance's private IP and port (6379 for Redis, 11211 for Memcached). Because the instance is on a VPC, you need a client in the same VPC or use VPC Peering or Cloud VPN. Memorystore does not support public IP addresses.
High Availability and Failover
Standard tier Redis uses a master-replica configuration with automatic failover. If the master fails, the replica is promoted within seconds. The failover is triggered by a health check that detects unavailability. During failover, writes may be lost if not using AOF persistence with "always" setting. Memcached has no built-in HA; you must use client-side sharding or deploy multiple instances.
Persistence Options for Redis
You can enable persistence via RDB (point-in-time snapshots) or AOF (append-only file). RDB is configured with a frequency (e.g., every 60 seconds if 1000 changes). AOF logs every write operation. Both impact performance. For maximum durability, use AOF with fsync every second. Persistence is off by default.
Maintenance and Scaling
Google applies automatic maintenance (security patches, version upgrades) during a configurable maintenance window. You can scale memory up or down (for Redis) without downtime, though scaling down requires enough free memory. Memcached scaling requires creating a new instance and re-sharding.
Monitoring and Logging
Memorystore integrates with Cloud Monitoring and Logging. Key metrics: CPU utilization, memory usage, cache hit ratio, and number of connections. You can set alerts for high memory usage (e.g., >80%) or low hit ratio. Cloud Logging captures instance logs for troubleshooting.
Security
Memorystore instances are accessible only within the VPC. You can configure firewall rules to restrict access to specific source IP ranges. Redis supports AUTH password (disabled by default). For encryption in transit, use Redis 6.0+ with TLS enabled. Memcached does not support encryption. For encryption at rest, Memorystore encrypts data using Google-managed keys; you can use CMEK for Redis.
Best Practices
Use Standard tier for production workloads requiring HA.
Set appropriate eviction policy (e.g., allkeys-lru for general caching).
Monitor cache hit ratio; if below 80%, increase instance size or optimize access patterns.
Use connection pooling to avoid connection overhead.
For Redis persistence, evaluate trade-off between durability and performance.
Limitations
Maximum memory size: 300 GB for Redis, 64 GB for Memcached.
No cross-region replication; use application-level multi-region caching.
Memcached does not support persistence or replication.
Instance IP address cannot be changed after creation.
Exam Tip
Know the differences between Redis and Memcached. The exam often asks which service to use for specific requirements (e.g., need data structures? Use Redis. Need simple caching with low overhead? Use Memcached). Understand that Memorystore is a managed service—you don't SSH into instances. Remember that Standard tier provides a replica and auto-failover.
Choose Redis or Memcached
First, decide which engine fits your workload. If you need complex data types (lists, sets, sorted sets), persistence, or replication, choose Redis. If you need a simple, high-throughput cache with minimal overhead and data loss is acceptable, choose Memcached. The exam may present a scenario with specific requirements; match them correctly.
Select Tier and Size
Choose between Basic (no replication) and Standard (with replica and auto-failover) tiers. For production, use Standard. Specify memory size (1–300 GB for Redis, 1–64 GB for Memcached). The size determines cost and capacity. Ensure the size is sufficient for your dataset plus overhead (typically 20% extra for Redis replication buffers).
Configure Network and Security
The instance is placed in your VPC network. You must specify the network and optionally a reserved IP range. By default, the instance gets an IP from the VPC's primary range. Configure firewall rules to allow inbound traffic from your application's IP ranges on port 6379 (Redis) or 11211 (Memcached). For Redis, enable AUTH password and TLS if needed.
Create the Instance
Use gcloud, Console, or Terraform to create the instance. The creation takes a few minutes. During creation, the instance is provisioned and health checks begin. Once the status is 'READY', you can connect. Example gcloud command: gcloud redis instances create my-redis --size=5 --region=us-central1 --tier=standard --network=default.
Connect Application
Update your application's cache client configuration to point to the instance's private IP address. For Redis, use a connection string like redis://10.0.0.3:6379. For Memcached, use the IP and port 11211. Implement connection pooling to reuse connections. Test connectivity from a VM in the same VPC using redis-cli -h 10.0.0.3 ping.
Monitor and Tune
After deployment, monitor key metrics: cache hit ratio, memory usage, CPU, and connections. If hit ratio is low, consider increasing instance size or adjusting eviction policy. Set up alerts for memory >80% to avoid OOM errors. For Redis, enable persistence if needed. Periodically review maintenance events and scaling needs.
Enterprise Scenario 1: E-Commerce Product Catalog
A large e-commerce platform uses Cloud Memorystore for Redis to cache product details, prices, and inventory counts. The backend database (Cloud SQL) handles updates but reads are served from cache. The Redis instance is 10 GB Standard tier with allkeys-lru eviction. The cache hit ratio is 95%, reducing database load by 80%. During Black Friday, traffic spikes cause memory usage to hit 90%. The team scales up to 20 GB without downtime. They use AOF persistence with fsync every second to minimize data loss on failover. When a master fails, the replica promotes in under 10 seconds, and the application's connection pool detects the new master using Redis Sentinel (configured externally). The key lesson: size for peak load and monitor memory closely.
Enterprise Scenario 2: Gaming Leaderboard
A mobile gaming company uses Redis sorted sets to maintain real-time leaderboards. Each game session updates scores, and the top 100 players are displayed. They use a 5 GB Basic tier instance because data loss is acceptable (scores are also stored in Firestore). The application uses ZADD and ZREVRANGE commands. The cache hit ratio is not critical since leaderboard data is always fresh. However, they encountered a problem: the eviction policy (volatile-lru) expired keys too aggressively, causing some scores to disappear. They switched to allkeys-lru and set a TTL of 1 hour on each key. The lesson: understand eviction policies and set TTLs appropriately.
Enterprise Scenario 3: Session Store for Web App
A SaaS provider uses Memcached for session storage across a fleet of web servers. They chose Memcached for its simplicity and low latency. They run multiple Memcached instances behind a client-side consistent hashing library. Each instance is 4 GB. When a node fails, the sessions on that node are lost, causing users to log in again. To mitigate, they use a secondary database for session persistence and accept the trade-off. They monitor cache hit ratio and add instances as traffic grows. The lesson: Memcached is simple but lacks replication; plan for data loss.
What the ACE Exam Tests
Objective 2.3 covers selecting appropriate data storage services. For Memorystore, the exam tests your ability to choose between Redis and Memcached based on requirements. Specific topics include:
Differences in data structures, persistence, replication, and eviction policies.
Standard vs. Basic tier and when to use each.
How to connect from Compute Engine, GKE, and Cloud Functions.
Scaling and maintenance behaviors.
Security features (private IP, AUTH, TLS, CMEK).
Common Wrong Answers
Choosing Memcached when persistence is required: Candidates assume Memcached can persist data. It cannot. The correct answer is Redis with AOF.
Selecting Basic tier for production workloads: Basic has no replica or auto-failover. Standard tier is required for HA.
Thinking Memorystore supports public IPs: It does not. All connections must be within VPC or via VPC Peering/Cloud VPN.
Believing Memcached supports replication: It does not. For replication, use Redis Standard tier.
Numbers and Values to Memorize
Redis max memory: 300 GB. Memcached max: 64 GB.
Default Redis port: 6379. Memcached: 11211.
Standard tier provides one replica and auto-failover.
AUTH password is disabled by default.
TLS is supported for Redis 6.0+.
Persistence options: RDB (snapshot) and AOF (append-only file).
Eviction policies: allkeys-lru (most common), volatile-lru, allkeys-random, volatile-ttl, noeviction.
Edge Cases
If you need cross-region replication, Memorystore does not support it; use application-level caching.
Scaling down requires that the current memory usage is less than the new size; otherwise, it fails.
Maintenance events can cause a brief failover; plan for it.
For Redis with persistence, enabling AOF can double write latency.
How to Eliminate Wrong Answers
When a question asks for a caching solution with specific features, map each feature to Redis or Memcached:
- Need sorted sets? → Redis. - Need replication? → Redis Standard tier. - Need persistence? → Redis (Memcached never). - Need simple key-value with max throughput? → Memcached. - Need TLS? → Redis (Memcached no). - Need to scale beyond 64 GB? → Redis (Memcached max 64 GB). Then eliminate options that mismatch.
Cloud Memorystore supports two engines: Redis and Memcached. Redis is feature-rich; Memcached is simple and fast.
Standard tier provides a read replica and automatic failover; Basic tier is a single node with no HA.
Memorystore instances are accessible only via private IP within the same VPC or through VPC Peering/Cloud VPN.
Redis max memory is 300 GB; Memcached max is 64 GB.
Redis persistence options: RDB (point-in-time snapshots) and AOF (append-only log). Memcached has no persistence.
Default ports: Redis 6379, Memcached 11211.
AUTH password is disabled by default; enable it for Redis security.
Monitor cache hit ratio; below 80% indicates need for larger instance or better access patterns.
Scaling up/down for Redis is live; for Memcached, you must create a new instance.
Memorystore does not support cross-region replication; use application-level caching for multi-region.
These come up on the exam all the time. Here's how to tell them apart.
Redis
Supports complex data types: strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, streams.
Optional persistence via RDB snapshots or AOF logs.
Supports master-replica replication (Standard tier) and automatic failover.
Multiple eviction policies: allkeys-lru, volatile-lru, allkeys-random, volatile-ttl, noeviction.
Supports TLS encryption in transit (Redis 6.0+).
Memcached
Only supports simple key-value strings.
No persistence; data is lost on restart.
No native replication or failover; use client-side sharding.
Only LRU eviction policy.
No encryption support; use network-level security.
Mistake
Memorystore instances can be accessed over the internet using a public IP.
Correct
Memorystore only provides private IP addresses within a VPC. There is no public IP option. To access from outside the VPC, you must use Cloud VPN, VPC Peering, or a proxy.
Mistake
Memcached supports data persistence and replication.
Correct
Memcached is purely in-memory. It does not persist data to disk and does not support native replication. Data is lost on restart. Redis is required for persistence and replication.
Mistake
You can SSH into a Memorystore instance to run commands.
Correct
Memorystore is a fully managed service. You cannot SSH into the underlying VM. All management is done via the Console, gcloud, or API. You interact with the cache only through the Redis/Memcached protocol.
Mistake
Basic tier provides high availability with automatic failover.
Correct
Basic tier is a single node with no replica. If the node fails, the instance becomes unavailable until Google restores it. Only Standard tier provides a replica and automatic failover.
Mistake
You can change the IP address of a Memorystore instance after creation.
Correct
The IP address is assigned at creation and cannot be changed. To use a different IP, you must create a new instance and migrate your data.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Ensure both resources are in the same VPC network. Use the private IP address of the Memorystore instance (e.g., 10.0.0.3) and the appropriate port (6379 for Redis, 11211 for Memcached). From a Compute Engine VM, you can test connectivity using redis-cli -h 10.0.0.3 ping for Redis. For applications, configure the client library with the IP and port. No public IP is available.
Yes, but only if the Cloud Function is connected to the same VPC via a VPC connector. Create a Serverless VPC Access connector in the same region and network as the Memorystore instance. Then configure the Cloud Function to use that connector. The function can then connect to the instance's private IP.
When the master node becomes unavailable, the replica is automatically promoted to master. This typically takes 10–30 seconds. During failover, writes to the old master may be lost if not using AOF persistence with fsync always. After promotion, the new master's IP address remains the same (the VIP is moved). The application should handle connection retries.
Use RDB for point-in-time backups with lower performance impact. Use AOF for better durability (every write logged). AOF with fsync every second offers a good balance. For maximum durability, use both. RDB snapshots can be scheduled (e.g., every 60 seconds if 1000 changes). AOF files can be rewritten periodically to reduce size.
Yes. One method is to use redis-cli with the MIGRATE command or use a dump/restore approach. Export an RDB file from your on-premises Redis, upload it to Cloud Storage, then import it into a new Memorystore instance using the gcloud redis instances import command. Example: gcloud redis instances import my-redis --region=us-central1 --source=gs://my-bucket/dump.rdb.
The maximum number of client connections depends on the instance size. For Redis, the default maxclients is 10,000 for instances up to 5 GB, 50,000 for larger instances. For Memcached, the limit is based on available file descriptors; typically 10,000+ connections are supported. You can check current connections using Redis INFO command.
No, Cloud Memorystore for Redis does not support Redis Cluster (sharding). It provides a single endpoint. For sharding, you must implement client-side sharding or use a third-party proxy. Memcached also requires client-side sharding.
You've just covered Cloud Memorystore for Redis and Memcached — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?