Service 14

Memorystore

In-MemoryManagedRedis / Memcached

Memorystore is Google's fully managed in-memory database service, offering Redis and Memcached as managed offerings. Because all data is stored in RAM, Memorystore delivers sub-millisecond access latency that no disk-based database can match — the correct choice for caching, session storage, rate limiting, leaderboards, and any access pattern where latency is the primary constraint.

Engine Options

Memorystore for Redis is the primary offering for most use cases. Redis is a data structure server supporting strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, geospatial indexes, pub/sub, and Lua scripting.

Memorystore for Valkey runs Valkey — an open-source Redis fork maintained by the Linux Foundation after the 2024 Redis license change. The wire protocol and client libraries are Redis-compatible, so existing applications connect without code changes. Choose Valkey when you want to stay on a permissively licensed engine.

Memorystore for Memcached provides simple distributed caching with a multi-threaded architecture. No persistence, no replication, no data structures beyond key-value strings. Use it only when migrating an existing application that already uses Memcached. For new projects, choose Redis or Valkey.

Redis Service Tiers

Tier	Availability	Use case
Basic	Single node, no replication	Development and testing only. No SLA.
Standard	Primary + replica, automatic failover	Production caching. ~99.9% SLA.
Cluster	Multiple shards, each with a replica — the separate Memorystore for Redis Cluster product	Large datasets or very high throughput.

For production, always use Standard or Cluster. Basic has no replica — a failure loses the entire cache. Applications must handle cache misses gracefully regardless of tier.

Redis Persistence

Standard-tier Memorystore for Redis supports RDB snapshots only — AOF is not available on the standard offering. The separate Memorystore for Redis Cluster product adds AOF persistence (you choose AOF or RDB, not both). Either way, for use cases where data loss between snapshots is unacceptable, reconsider whether Redis is the right tool — Firestore or Cloud SQL provide stronger durability guarantees.

Eviction Policies

When a Redis instance reaches its memory limit, it must evict keys. Key policies:

allkeys-lrucache

Evicts the least-recently-used key from the whole keyspace. The right default when Memorystore is a cache — old entries make room for new.

volatile-lrumixed use

Evicts LRU only among keys with a TTL. Keys without an expiry are never evicted — use when some data must persist while cache entries cycle.

noevictionstore

Evicts nothing — writes fail at the limit. The open-source Redis default (not Memorystore's), and wrong for a cache: a full instance starts rejecting writes instead of making room.

allkeys-lru: Evict the least-recently-used key across all keys. Best general-purpose default for cache workloads.
volatile-lru: Evict LRU keys only among those with a TTL. Keys without TTLs are never evicted.
noeviction: Return write errors when full. Appropriate when writes must fail rather than silently drop data — but that needs explicit error handling, and Redis is rarely the right primary durable store.

For production caches, choose and document the eviction policy intentionally. Memorystore defaults to volatile-lru, which evicts only keys that carry a TTL — keys without an expiry can still fill the instance until writes fail, which is rarely the right behavior for a cache.

Cache Invalidation Strategy

The right strategy depends on how much stale data you can tolerate and how often the underlying data changes. Most real systems combine two of these — for example, TTL-based expiration as a safety net plus event-driven invalidation for known critical keys.

TTL-based expiration: every cached key expires after a configurable time-to-live.
Write-through: update the cache on every write to the primary database. Always current, adds write latency.
Cache-aside (lazy loading): populate only on cache miss. Simpler but can cause thundering herd.
Event-driven invalidation: a database change event triggers cache key deletion. Fresh without TTL-based lag.

Common Mistakes

Using Basic tier in production — any failure empties the cache and may expose the primary database to full load.
Keeping the default volatile-lru on a cache whose keys have no TTL — the instance fills until writes fail. Configure allkeys-lru for cache workloads.
Treating Redis as a durable primary data store. Data loss between snapshots is a real risk.
No cache invalidation strategy — stale data is far harder to debug than a cache miss.
Under-sizing memory relative to the working dataset.

Best Practices

Use Standard tier for production caching. Use Cluster for datasets exceeding single-node capacity.
Configure allkeys-lru eviction as the default for cache workloads.
Set TTLs on all cached keys.
Design and document a cache invalidation strategy before deploying.
Monitor cache hit rate — below 90% indicates under-sizing or incorrect TTLs.
Use VPC-native connectivity; never expose Memorystore over a public IP.

Comparable services AWS ElastiCache for Redis / Memcached Azure Azure Cache for Redis

Knowledge Check

For a new project needing in-memory caching, which Memorystore engine should you choose?

Memcached — its simpler architecture is always the preferable starting point for any brand-new project, regardless of the use case
Redis — richer data structures, persistence, replication, and pub/sub; Memcached is mainly for migrating existing Memcached apps
Either one — they are functionally equivalent for ordinary caching workloads
Memcached — its multi-threaded architecture delivers meaningfully higher throughput than Redis

What is the risk of using Memorystore for Redis Basic tier in production?

Basic tier silently disables TTL-based key expiration, so cached keys never expire on their own and must be deleted manually
Basic tier caps instance size at 1 GB, which is insufficient for most production workloads
Basic tier has no replica — any failure empties the entire cache and may expose the primary database to full load
Basic tier does not support any Redis data structures beyond simple key-value strings

Which eviction policy is recommended as the default for cache workloads?

noeviction — prevents any data loss by returning write errors to clients once the instance is completely full of keys
volatile-lru — evicts only the keys that have a TTL set, protecting keys without any expiry
allkeys-lru — evicts the least-recently-used key across all keys, the best general-purpose default for caches
volatile-ttl — evicts the keys with the shortest remaining TTL first

What persistence mechanism does standard-tier Memorystore for Redis support?

Both RDB snapshots and AOF (append-only file) persistence running together
Continuous streaming replication of every write to Cloud Storage, with no data loss window at all
RDB snapshots only — data written between snapshots can be lost if the instance fails
No persistence at all — every byte of data is lost on restart, by design

What is the cache-aside (lazy loading) invalidation strategy?

The cache is updated synchronously on every single write to the primary database, so that it always stays perfectly current at all times
A database change event triggers immediate deletion of the corresponding cache key
The cache is populated only on a cache miss — the app checks the cache, and on a miss fetches from the database and writes it back
All keys are set with a TTL and expire automatically without any application intervention

You got correct