Caching with Memorystore

Introduction to Memorystore on GCP

For the Professional Cloud Developer (PCD) exam, Memorystore is the answer whenever a scenario mentions sub-millisecond latency, hot keys overwhelming Cloud SQL, session state for stateless Cloud Run services, or rate-limiting counters shared across GKE pods. Google Cloud now ships three Memorystore engines that you must distinguish on the exam:

• Memorystore for Redis — the original managed offering, currently supporting Redis 7.2, 7.0, 6.x, 5.0, 4.0, 3.2, with Basic (single node) and Standard (1 replica HA) tiers. Maximum instance size is 300 GB.
• Memorystore for Memcached — managed Memcached 1.5/1.6, multi-node multi-threaded, no persistence, no HA per node, ideal for raw throughput.
• Memorystore for Valkey — newer Google-managed Valkey 7.2 (the open-source fork of Redis after the licence change), shipping with cluster mode by default and shard-level high availability.

白話文解釋（Plain English Explanation）

Caching is the difference between rummaging through a 500-page reference manual every time someone asks you a trivia question, and pinning the top 20 answers to a sticky note on your monitor.

Analogy 1 — The Restaurant Pass-Through Window

Your database (Cloud SQL, Firestore, Spanner) is the cold storage walk-in fridge at the back of the restaurant. Every trip there costs the chef 30 seconds of walking. Memorystore for Redis is the pass-through window between the line cook and the dishwasher — the cook drops the most-ordered ingredients (top user profiles, product prices, session tokens) on the window. The next time anyone needs them, it is a 0.5 ms grab instead of a 50 ms fridge trip. When the cache is full, the oldest items get tossed (allkeys-lru) to make room.

Analogy 2 — The Toll Booth EZ-Pass Lane

Memorystore for Memcached is an EZ-Pass lane at a toll booth. There is no fancy data structure, no persistence, no transponder memory — only a flat list of plate numbers and balances. Many lanes run in parallel (Memcached is multi-threaded and sharded), so a million cars per hour pour through without queuing. But if the booth loses power, the list is gone — that is acceptable because the DMV is the source of truth, not the booth.

Analogy 3 — The Hot Water Tank vs. The Tankless Heater

A Basic Tier Redis instance is like a single hot water tank in your basement. If it bursts at 2 a.m., you have a cold shower until someone shows up. A Standard Tier instance is a tank with an automatic backup tank — when the primary fails, the second one kicks in within seconds and your shower stays warm. Valkey cluster mode is a row of tankless heaters across many bathrooms — each room (shard) heats its own water in parallel, and if one heater fails its partner downstairs covers the same room.

Memorystore for Redis — Basic vs Standard Tier

The tier is the single most exam-relevant decision for Redis.

Basic Tier characteristics

• Single node, no replica, no automatic failover.
• Supports instance sizes from 1 GB to 300 GB.
• During scale or maintenance, the cache flushes — the instance becomes unavailable briefly.
• Cheapest option, suitable for non-critical caches, dev/test, or workloads that can tolerate a cold cache rebuild from the primary database.

Standard Tier characteristics

• One primary plus one replica in a different zone of the same region.
• Automatic failover in the order of tens of seconds when the primary becomes unhealthy.
• Read replicas (up to 5 read replicas total) can be enabled on Standard Tier instances 5 GB or larger, exposing a separate read endpoint for scaling read throughput.
• Supports maintenance windows so failovers happen during predictable hours.

Choosing between tiers

Treat Standard Tier as the default for any production scenario. The cost delta is roughly 2× memory price, but the SLA jumps from no commitment on Basic to 99.9% on Standard Tier. On the exam, "session store for a customer-facing app on Cloud Run" is always Standard Tier because session loss equals user logout.

Memorystore for Memcached Deep Dive

Memorystore for Memcached is the workhorse for plain key/value caching at massive scale.

Architecture and sizing

• An instance is a cluster of nodes (1 to 20 nodes per instance).
• Each node provides 1 GB to 256 GB of RAM, 1 to 32 vCPU, and Memcached scales horizontally by adding more nodes.
• Total maximum instance memory: 5 TB (20 nodes × 256 GB).
• The client uses the Auto Discovery protocol (port 11211) to learn the node list and consistently hash keys across nodes.

Trade-offs versus Redis

• No persistence — Memcached is purely in-memory. A node restart flushes its slab.
• No replication — losing a node loses that node's slice of keys.
• No data structures beyond strings. No lists, sets, sorted sets, streams, or Pub/Sub.
• Multi-threaded per node — Memcached uses all vCPUs efficiently, whereas a single Redis node remains largely single-threaded for command execution.

When to pick Memcached on the exam

• Read-heavy caching of computed query results.
• Session caches where session loss is tolerable.
• Scenarios that emphasise "linear horizontal scale" and "no need for data structures."

Memorystore for Valkey — The New Default

After the Redis licence change in 2024, the Linux Foundation forked the engine into Valkey. Google added Memorystore for Valkey to the lineup with deliberate design choices that differ from the legacy Redis service.

Engine and topology

• Valkey 7.2 as the only engine version at launch.
• Cluster mode is always on: instances are made of 1 to 250 shards, each shard is one primary plus 0, 1, or 2 replicas.
• Total instance memory: up to 14.5 TiB.
• Native zonal HA — replicas always sit in a different zone from the primary.

When to choose Valkey over Redis

• You need more than 300 GB in one logical cache (the Redis service ceiling).
• You want cluster mode from day one without managing shard topology in Redis Enterprise.
• You want to stay on the OSI-licensed branch going forward — Valkey is BSD-3, while Redis 7.4+ uses RSALv2/SSPL.

Migration notes

• Most Redis clients (go-redis, redis-py, jedis, ioredis, lettuce) speak the Valkey wire protocol unchanged.
• Lua scripts and MULTI/EXEC transactions behave identically.
• Some Redis Stack modules (RediSearch, RedisJSON) are not part of Memorystore for Valkey — if a scenario mentions JSON search, you may be looking at a self-hosted setup or a Redis Enterprise migration.

Failover Behavior and SLA

Redis Standard Tier failover

When the primary node becomes unhealthy, Memorystore promotes the replica in the secondary zone. The published failover time target is under 60 seconds under normal conditions, often 15–30 seconds observed. The endpoint IP and port stay the same, so your client only sees a brief connection reset.

Read replica failover

For Standard Tier with read replicas, the read endpoint balances across all healthy replicas using round-robin DNS. If one replica fails, traffic drains to the surviving replicas within seconds. The primary endpoint is unchanged.

Valkey shard failover

In Valkey, each shard fails over independently. A primary failure in shard 7 promotes shard 7's replica without touching shards 1–6 or 8–250. Clients using cluster-aware drivers handle the redirection via the MOVED and ASK responses automatically.

RDB and AOF Persistence

Although Memorystore is a cache first, the Redis and Valkey engines support two persistence modes that can rebuild state after a full restart.

RDB snapshots

• RDB writes a point-in-time binary snapshot to a Google-managed Cloud Storage bucket.
• Configurable snapshot intervals: 1 hour, 6 hours, 12 hours, or 24 hours.
• Snapshots are compressed and encrypted at rest with Google-managed keys (CMEK supported on supported tiers).
• After a full instance restart or zone outage where both nodes are lost, Memorystore restores from the most recent RDB snapshot — meaning up to one snapshot interval of writes can be lost.

AOF (Append-Only File)

• AOF is supported on Memorystore for Valkey (and on certain Redis cluster configurations) and writes every command to an append-only log.
• Sync policies match upstream Redis: always (per command), everysec (per second, the default), or no (let the OS flush).
• AOF provides much tighter RPO — typically under one second of data loss — at the cost of write amplification.

Choosing persistence

Treat persistence as insurance for cache warm-start, not as a primary datastore. Even with AOF always, the system of record remains Cloud SQL, Firestore, or Spanner. On the exam, persistence settings are answers to "minimize cache cold-start time after a regional restart," not to "store user-critical data."

Memory Management and Eviction Policies

When a Memorystore instance reaches its maxmemory limit, Redis enforces an eviction policy to make room for new writes.

The policies the exam expects you to know

• noeviction — return an error on writes when full. Use when the cache must never silently drop keys.
• allkeys-lru — evict the least recently used key from the entire keyspace. The most common choice for general-purpose caches.
• allkeys-lfu — evict the least frequently used key. Better for workloads where some keys are hot but rarely re-accessed.
• volatile-lru — evict the least recently used key only among keys with a TTL set. Keys without EXPIRE are protected.
• volatile-lfu — same as above but using LFU statistics.
• volatile-ttl — evict the key with the shortest remaining TTL first.
• allkeys-random / volatile-random — random selection, mainly for benchmarks.

Configuration

You set the policy via the maxmemory-policy parameter at instance creation or update time:

gcloud redis instances update my-cache \
  --region=us-central1 \
  --update-redis-config maxmemory-policy=allkeys-lru

Default and gotchas

Memorystore for Redis defaults to volatile-lru. If your application never sets TTLs, volatile-lru becomes effectively noeviction and your writes start failing once memory is full. The fix is either to set a default TTL in code or switch to allkeys-lru.

Read Replicas and Cluster Mode

Read replicas (Redis Standard Tier)

• Up to 5 read replicas total on instances of 5 GB or larger.
• Each replica is asynchronously kept in sync from the primary.
• A separate read endpoint (a regional load-balanced DNS name) distributes connections across all replicas.
• Reads may be stale by milliseconds — never use the read endpoint for a write-then-read flow.

Cluster mode

• Memorystore for Redis Cluster and Memorystore for Valkey both expose true cluster mode.
• Keyspace is split across shards using hash slots (0–16383, the standard Redis algorithm).
• Clients must support cluster mode (cluster-enabled: true in the driver) to handle MOVED and ASK redirections.
• Multi-key operations across shards require hash tags — keys wrapped in {tag} hash to the same slot. Without hash tags, MGET user:1 user:2 may straddle shards and fail.

Scaling

• Vertical scaling — change the instance size to add memory.
• Horizontal scaling — Redis Cluster and Valkey allow adding shards online without flushing the cache.
• Read replicas scale reads only; they do not increase write throughput.

Security — AUTH, In-Transit Encryption, and IAM

AUTH

• AUTH is the Redis password mechanism. Memorystore generates a 128-character random token when AUTH is enabled on an instance.
• Retrieve the password via:

gcloud redis instances get-auth-string my-cache --region=us-central1

• The client sends AUTH <password> immediately after connecting.

In-transit encryption (TLS)

• Memorystore offers server-authenticated TLS on Redis and Valkey instances.
• The server certificate chains to a Memorystore CA — download it via gcloud redis instances describe and pin it in the client TLS context.
• Memcached does not support TLS in Memorystore; isolate it with VPC-level controls only.

Encryption at rest

• All RDB and AOF artefacts are encrypted at rest with Google-managed keys by default.
• CMEK (Customer-Managed Encryption Keys via Cloud KMS) is available on Memorystore for Redis Standard Tier and Memorystore for Valkey.

IAM

• Memorystore uses IAM for instance management (create, delete, configure) — roles like roles/redis.admin, roles/redis.editor, roles/redis.viewer.
• Data-plane access (issuing GET/SET commands) is not governed by IAM — that is the job of AUTH + network controls.

Private Services Access and VPC Connectivity

Memorystore instances always live on a private IP — there is no public endpoint.

Private Services Access (PSA)

• Memorystore for Redis and Valkey cluster allocate IP addresses from a Private Services Access range you reserve in your VPC.
• You configure PSA once per VPC:

gcloud compute addresses create google-managed-services-default \
  --global --purpose=VPC_PEERING --prefix-length=16 \
  --network=default

gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-default --network=default

• After this, any Memorystore instance in that VPC draws from the reserved range.

Connectivity from Cloud Run

• Cloud Run runs in a Google-managed tenant network, not in your VPC.
• To reach Memorystore from Cloud Run, attach a Serverless VPC Access Connector (Direct VPC Egress also works on second-generation Cloud Run).
• Egress setting all-traffic routes every Cloud Run egress packet through your VPC, while private-ranges-only is enough for Memorystore since its IPs are RFC1918.

Connectivity from GKE

• A regional GKE cluster sits inside the VPC, so pods can reach Memorystore over the node's primary IP directly.
• Use VPC-native (alias IP) clusters; legacy route-based clusters can hit MTU and route limits.
• For multi-cluster setups, ensure all clusters peer with the same Memorystore PSA range, or place instances behind Private Service Connect endpoints for per-cluster isolation.

Connectivity from on-prem

• Reach Memorystore from on-prem only via Cloud VPN or Cloud Interconnect plus custom route advertisements that include the PSA range.

Common Cache Patterns

The PCD exam tests three classic cache patterns, sometimes by name and sometimes by behaviour.

Cache-aside (lazy loading)

1. Application reads from Memorystore first.
2. On a miss, it reads from the system of record (Cloud SQL, Firestore).
3. It writes the value back to Memorystore with a TTL.
4. On writes to the database, it optionally invalidates the cache key.

This is the default for most Cloud Run and GKE apps because the cache is populated on demand and survives full cache flushes — the worst case is a cold-cache latency spike, not data loss.

Write-through

1. Application writes to Memorystore.
2. Memorystore (or a wrapper layer in app code) synchronously writes to the database.
3. Reads always hit Memorystore first.

Pros: cache is always warm and consistent with the database. Cons: write latency is the sum of cache plus database latency, and a Memorystore outage breaks writes.

Write-behind (write-back)

1. Application writes to Memorystore only.
2. A background worker (Cloud Functions, Cloud Run job, or in-app goroutine) flushes the write to the database asynchronously.

Pros: lowest write latency. Cons: if Memorystore loses data before the flush, writes are lost — only acceptable when the data is recoverable or the loss budget is generous.

Pattern selection on the exam

• "Read-heavy product catalog with occasional updates" → cache-aside with TTL.
• "Strong consistency between cache and database is critical" → write-through.
• "Burst-write workload, eventual consistency is OK" → write-behind, possibly with Pub/Sub as the durable queue between cache and database.

Operational Concerns — Monitoring, Maintenance, Cost

Monitoring

Memorystore exports metrics to Cloud Monitoring under the redis.googleapis.com/ and memcache.googleapis.com/ prefixes. Key metrics:

• redis.googleapis.com/stats/memory/usage_ratio — memory consumed vs maxmemory.
• redis.googleapis.com/stats/cpu_utilization — single-core utilisation on the Redis engine.
• redis.googleapis.com/clients/connected — total client connections; default cap is 65,000.
• redis.googleapis.com/keyspace/hits and keyspace/misses — derive hit ratio.

Set alerts at 80% memory utilisation and 75% CPU to give yourself headroom before evictions start dominating CPU.

Maintenance windows

Each Standard Tier and Valkey instance has a weekly maintenance window of one hour during which Google performs patches. You can pick a day (Sunday–Saturday) and hour. During the window the replica is patched first, then a controlled failover patches the primary.

Cost optimisation

• Size by working set, not total dataset. If 5 GB of hot keys serves 99% of requests, a 5 GB Standard instance beats a 50 GB Basic instance.
• Use read replicas instead of doubling the primary's memory if the bottleneck is read throughput.
• Memcached's flat per-node pricing makes it cheaper than Redis Standard Tier for pure key/value at high RPS.

Frequently Asked Questions (FAQs)

Q1: When should I choose Memorystore for Valkey over Memorystore for Redis?

A1: Choose Valkey when you need more than 300 GB total memory, want cluster mode by default, or want to stay on the BSD-3 licensed branch. Valkey 7.2 is wire-compatible with most Redis clients, so migration is mostly a connection string change.

Q2: Does Memorystore support TLS for client connections?

A2: Yes — Memorystore for Redis and Memorystore for Valkey both support server-authenticated TLS. You enable it at instance creation, then download the server CA via gcloud redis instances describe and pin it in your client. Memcached on Memorystore does not support TLS; protect it at the VPC layer.

Q3: How do I reach Memorystore from Cloud Run?

A3: Cloud Run cannot reach private IPs directly. Attach a Serverless VPC Access Connector (or use Direct VPC Egress on second-generation Cloud Run) and set the connector's subnet to the VPC where Memorystore lives. The Cloud Run service then connects to the Memorystore endpoint over the connector.

Q4: What is the default eviction policy and why does it matter?

A4: Memorystore for Redis defaults to volatile-lru, which only evicts keys that have a TTL. If your code never sets TTLs, the cache fills up and writes start failing with "OOM command not allowed when used memory > 'maxmemory'." Either set TTLs via EXPIRE or change the policy to allkeys-lru.

Q5: Can I use Memorystore as a Pub/Sub message broker?

A5: Redis Pub/Sub works on Memorystore but provides at-most-once delivery and no persistence — subscribers that disconnect lose every message in the meantime. For durable messaging always use Google Cloud Pub/Sub. Redis Pub/Sub is acceptable only for ephemeral fan-out signals (cache invalidations, live presence updates).

Q6: What is the largest Memorystore instance I can provision?

A6: Memorystore for Redis tops out at 300 GB per instance. Memorystore for Memcached supports up to 5 TB per instance (20 nodes × 256 GB). Memorystore for Valkey supports up to 14.5 TiB per instance via cluster mode (up to 250 shards).

Q7: Does Memorystore back up data?

A7: Memorystore for Redis and Valkey support RDB snapshots at 1, 6, 12, or 24-hour intervals into Google-managed Cloud Storage, and Valkey additionally supports AOF persistence. Memcached has no persistence — its data is lost on node restart.