Memorystore is Google Cloud’s fully managed in-memory data service, built on popular open source engines.

Computers store data in two broad ways. Disks, including solid state drives, keep data safely but respond in milliseconds or more. Memory, the RAM inside a server, responds in microseconds but is smaller, more expensive and empties when power or the process stops. An in-memory data store keeps its data in RAM so that reads and writes are extremely fast, and it exposes that data over the network so many application servers can share it.

Running such a store yourself is real work. You must install the software, choose machine sizes, set up replicas, configure failover, patch security issues, tune memory settings, and monitor everything around the clock. Memorystore takes over that work. You ask for an instance of a given size and engine, and Google provisions, secures, patches and monitors it, while you simply connect your application to it.

The problems it solves

The first problem is slow databases under heavy read load. When thousands of users request the same product page, asking the main database every time wastes its capacity. A cache in front answers repeat requests quickly and shields the database. The second problem is shared fast state, such as user sessions, shopping carts, rate limit counters and leaderboards, that many servers must read and update at high speed. The third problem is real-time messaging and counting, where speed matters more than long-term storage.

A short vocabulary unlocks every later chapter, so learn each term properly now.

Each concept below is explained by what it is, why it exists and where you will meet it. Terms such as cache hit and eviction appear constantly in design discussions.

Cache versus database

A cache is not a database. A database promises to keep data safely and answer questions about it. A cache promises only speed, and it is allowed to forget. This distinction guides nearly every design decision: the true source of truth should live in a durable database, while the cache holds copies that can always be rebuilt.

Memorystore is not one product but a family, and choosing the right member is your first decision.

Memorystore offers managed services for several engines. The lineup has evolved over time, so always confirm the current list and feature support in the official documentation. The broad picture is stable and is described below.

flowchart TD
  Q["What do you need?"] --> A{"Rich data structures or persistence?"}
  A -- No --> M["Memorystore for Memcached"]
  A -- Yes --> B{"Need very large scale or high throughput?"}
  B -- No --> R["Memorystore for Redis"]
  B -- Yes --> C["Memorystore for Redis Cluster or Valkey"]
        

A word on Redis and Valkey

Redis is an extremely popular in-memory engine. In 2024, changes to Redis licensing led the community to create Valkey as an open source fork under neutral governance, and cloud providers, including Google, added support for it. For most application code the two behave very similarly, since Valkey began as a continuation of Redis. Check the current compatibility notes if your application relies on newer or specialized features.

Behind a single connection address sits a small distributed system that Google runs for you.

A Memorystore instance consists of one or more nodes, each a virtual machine running the in-memory engine, placed in a Google-managed environment connected to your network. Your application servers, running on Compute Engine, Google Kubernetes Engine, Cloud Run or elsewhere, connect to the instance using private network addresses. You never see or manage the underlying machines.

flowchart LR
  APP1["App Server 1"] --> EP["Instance Endpoint"]
  APP2["App Server 2"] --> EP
  APP3["App Server 3"] --> EP
  EP --> P["Primary Node"]
  P --> R1["Replica Node in another zone"]
  CP["Google Managed Control Plane"] -.provisions, patches, monitors.-> P
  CP -.-> R1
  P --> DB["Source of Truth Database"]
        

The control plane and the data plane

As with many managed services, there are two layers. The control plane handles creating, resizing, updating and repairing instances. It is the part you talk to when you issue management commands. The data plane is the part that actually serves reads and writes to your application. Separating them means a management operation does not slow down normal traffic, and a busy cache does not block administration.

Zones and regions

An instance lives in a region, and its nodes live in zones within that region. In a highly available setup, the primary and replicas are placed in different zones so that the loss of one zone does not take the service away. Your applications should be in the same region to keep latency low, and ideally in the same zone as the primary for the fastest responses.

Following one request from the application to the cache and back shows where time is spent.

When your application needs a piece of data, it builds a key, sends a command to Memorystore over a network connection, and waits for the reply. Because the data is already in memory, the engine simply looks the key up and returns the value. Most of the elapsed time is actually the network trip between your server and the cache, not the lookup itself. That is why keeping applications close to the instance matters so much.

sequenceDiagram
  participant U as User
  participant A as Application
  participant C as Memorystore Cache
  participant D as Database
  U->>A: Request product page
  A->>C: GET product key
  alt Cache hit
    C-->>A: Value returned quickly
  else Cache miss
    C-->>A: Not found
    A->>D: Query database
    D-->>A: Product data
    A->>C: SET key with TTL
  end
  A-->>U: Page response
        

Why the engine is fast but single-minded

Redis-style engines traditionally execute commands on a main thread, one at a time. That keeps behavior simple and predictable and is the reason simple commands are so quick. It also means one slow command, such as scanning every key in a very large dataset, can make every other client wait. Fast access, then, depends on keeping commands small and cheap.

Caching is easy to start and hard to get right, and the pattern you choose decides how right.

A caching pattern is a rule for how data moves between your application, the cache and the database. Each pattern trades simplicity, freshness and write speed differently.

Cache-aside is the usual starting point

Cache-aside is the most common pattern because it is easy to reason about and fails gracefully. If the cache is empty or unavailable, the application still works, only more slowly, by reading from the database. It is the safe default for most applications.

Invalidation: the famously hard problem

When the underlying data changes, the cached copy becomes stale. There are two main strategies. One is to set a time to live so entries expire on their own, accepting a short window of staleness. The other is to delete or update the cached entry whenever the data changes. Many systems use both: explicit invalidation on writes, with a TTL as a safety net in case an invalidation is missed.

flowchart TD
  W["Data is updated in the database"] --> I{"Invalidation strategy"}
  I --> E["Delete cache entry now"]
  I --> T["Wait for TTL to expire"]
  I --> U["Write new value to cache"]
  E --> N["Next read reloads fresh data"]
  T --> S["Short stale window accepted"]
  U --> F["Cache is fresh immediately"]
        

The cache stampede

Imagine a very popular entry expires, and a thousand requests arrive at the same instant. All of them see a miss and all of them hit the database simultaneously. This surge is called a cache stampede, and it can overwhelm the very database the cache was protecting. Defenses include adding random variation to TTLs so entries do not expire together, allowing only one request to rebuild an entry while others wait, and refreshing hot entries before they expire.

Redis-style engines are much more than a simple key and value box.

Memcached stores plain strings. Redis and Valkey store several rich data types, and these types let you solve whole categories of problems directly inside the data store with fast, atomic operations. Atomic means an operation happens completely or not at all, with no other client able to see it half done.

Popular non-cache uses

Memory is the scarce resource, and everything about Memorystore reflects that.

An in-memory store can hold only as much as its memory allows. When it runs short, one of two things happens: it removes some data according to an eviction policy, or it refuses new writes and returns errors. Understanding which behavior you have configured is essential, because the wrong choice either loses data you wanted or breaks your application.

Eviction policies

For a pure cache, an all-keys policy based on recent or frequent use is usually right. For a mixed store, where some keys are cache entries and others are important state, a policy that evicts only keys with a TTL protects the important ones. The default policy of an instance may not match your needs, so choose deliberately.

Sizing the instance

Sizing begins with the working set, the amount of data you want to keep hot. Add overhead for the engine’s internal structures, which means that a thousand small keys cost more memory than their raw data alone. Then add headroom. Features such as replication, snapshots and the way memory is allocated need spare room, which is why Google recommends not filling an instance to the brim. Keep a comfortable margin below the maximum, and watch the memory usage metrics rather than guessing.

How much downtime you can tolerate decides which tier or architecture you need.

Servers fail. Memory modules fail, hosts get replaced, and zones occasionally have trouble. An availability design decides what happens to your cache when that occurs. Memorystore offers different levels of protection.

Basic tier

The Basic tier of Memorystore for Redis is a single node with no replica. It is the cheapest option and suits caches where a restart is acceptable. If the node fails, or during maintenance and certain scaling operations, the cache is unavailable and its contents are lost, so the application must fall back to the database and rebuild the cache. It does not carry the availability commitment of the replicated tier.

Standard tier

The Standard tier adds a replica in a different zone. The replica receives a continuous stream of writes from the primary. If the primary fails, the service promotes the replica to primary automatically, and the endpoint continues to serve traffic. Because replication is asynchronous, a very small amount of the most recent writes may be lost at the moment of failure. Standard tier is the normal choice for production caches and session stores. It also carries a service level objective, so check the current availability terms.

flowchart TD
  A["Primary in Zone A serving traffic"] --> R["Replica in Zone B stays in sync"]
  A -. "Primary fails" .-> F["Failure detected"]
  F --> P["Replica promoted to primary"]
  P --> E["Endpoint continues serving"]
  P --> N["New replica created and synced"]
        

Clustered offerings

Clustered services divide data into shards, and each shard can have one or more replicas placed across zones. A failure affects only the shard involved, and its replica takes over. Clusters also allow capacity and throughput to grow by adding shards. They are the choice for large datasets and for workloads where even brief unavailability of a big instance is unacceptable.

Client behavior during failover

Failover is only seamless if clients handle it well. During the switch, connections are dropped and a short period of errors can occur. A robust client library retries failed commands with a small delay, reconnects automatically, and refreshes its view of the cluster topology. Applications should expect brief errors and handle them gracefully rather than crashing.

Growing a cache means more memory, more throughput, or both, and each has its own tool.

As traffic and data grow, a single node eventually runs out of memory or network capacity. There are three ways to grow, and the right one depends on what is running short.

How keys are distributed in a cluster

Clustered Redis-style engines divide the key space into a fixed number of hash slots. Each shard owns a range of slots. A hash of the key decides which slot, and therefore which shard, holds it. This is automatic, but it creates a rule you must respect: operations that touch several keys at once must have all their keys in the same slot. Designers use hash tags, a marker inside the key name, to force related keys into the same slot when they need multi-key operations.

Memory forgets, so any data you cannot afford to lose needs a plan.

The key fact about in-memory stores is that their primary copy is volatile. If a process restarts without any saved state, the memory is empty. Some Memorystore options provide persistence features that periodically write data to disk so it can be restored, and others do not. The details differ by engine and tier and change over time, so confirm them in the current documentation.

Choosing a durability stance

For most designs, the cleanest approach is the disposable cache, where durability is irrelevant because the source of truth lives elsewhere. If you do keep important state, such as session data you would rather not lose, use a replicated tier with persistence and take regular exports to Cloud Storage. Practice restoring from them, because an untested backup is only a hope.

Memorystore is private by design, so connecting to it is a networking question first.

Memorystore instances do not live on the public internet. They receive private addresses and are reachable only from inside connected networks. Depending on the engine, connectivity is provided through private services access, which creates a private peering between your network and Google’s service network, or through Private Service Connect, which creates a dedicated private endpoint in your own network. The details differ by product, so follow the documentation for your engine.

flowchart LR
  subgraph YourVPC["Your VPC Network"]
    GCE["Compute Engine VMs"]
    GKE["GKE Pods"]
    CR["Cloud Run via VPC egress"]
  end
  GCE --> PRIV["Private connection"]
  GKE --> PRIV
  CR --> PRIV
  PRIV --> MS["Memorystore Instance"]
  OnPrem["On-premises network via VPN or Interconnect"] --> PRIV
        

Reaching it from different compute platforms

Latency and placement

Since most of a cache request’s time is the network trip, placement matters. Keep applications in the same region as the instance, and where possible in the same zone as the primary. Calls that cross regions add tens of milliseconds and defeat the purpose of a cache. Calls that cross zones add a small but measurable delay and may incur network charges.

An in-memory store often holds sessions and personal data, so it deserves the same care as a database.

Security for Memorystore has several layers. The first is network isolation: instances have private addresses and are reachable only from permitted networks. The second is authentication at the engine level, where clients must present credentials before running commands. The third is encryption of data in transit between clients and the instance. The fourth is access control for administration, using Google Cloud IAM to decide who may create, change or delete instances.

What to keep out of the cache

The speed of a cache tempts teams to put everything in it, including data that should never be copied around. Consider carefully whether highly sensitive values, such as full payment details or secrets, belong in a cache at all. Where you must cache personal data, apply short TTLs, encrypt in transit, restrict access tightly, and ensure that data deletion requests also clear cached copies.

Most Memorystore performance problems come from a small set of repeating causes.

Hot keys

A hot key is a single key receiving a disproportionate share of traffic. Because a key lives on one node, a hot key can overload that node even when the cluster as a whole is idle. The fix is to spread the load: replicate the value under several keys and pick one randomly on reads, cache the value inside the application for a short time as well, or restructure the data so no single key bears the whole load.

Big keys

A big key is a single key holding a huge value or collection, such as a list with millions of items. Reading or deleting it takes a long time, and because commands run one at a time, everyone else waits. Break large structures into smaller pieces and delete them incrementally.

Too many connections and no pooling

Each connection consumes memory and processing on the instance. Applications that open a new connection per request, or that scale to hundreds of servers each with many connections, can hit connection limits and waste resources. Use connection pooling, reuse connections, and limit the pool size per application instance.

Many small round trips

Making one network call per key is slow because each call pays the network delay. Group commands together using pipelining, where many commands are sent before waiting for replies, or use batch commands that fetch several keys at once. In clusters, keep batches to keys on the same shard when possible.

A cache that is quietly failing looks, from the outside, like a slow database, so you must watch it directly.

Memorystore publishes metrics to Cloud Monitoring and records administrative activity in Cloud Audit Logs. The right set of metrics tells you whether the cache is healthy, full, effective or under stress.

Alerts worth having

Maintenance and updates

Google periodically updates instances to patch security issues and apply improvements. You can often choose a preferred maintenance window so updates happen at quiet times. Replicated and clustered setups handle maintenance with limited disruption, while single-node instances may be briefly unavailable. Plan applications to tolerate short reconnections, and watch the maintenance notifications.

Drills and testing

Test what happens when the cache is empty, when it is slow, and when it disappears. Simulate failover. Measure how the database copes with a cold cache. These drills reveal whether the cache is a helpful accelerator or a hidden single point of failure.

Memorystore is priced mainly by how much memory you provision and for how long.

You are billed for the capacity of each instance for every hour it exists, whether or not it is busy. Larger instances cost more. Replicated tiers cost roughly in proportion to the extra memory they hold, since the replica is a second copy of the data. Clustered offerings are billed by the nodes that make up the shards and replicas. Additional charges can apply to network traffic that crosses zones or regions, to backups stored in Cloud Storage, and to the compute that connects to the instance. Pricing and discount programs, including possible committed use discounts, change over time, so check the current pricing page.

Cost versus value

The cost of a cache should be compared with what it saves. A well-placed cache can reduce the size and cost of a database, because the database handles far fewer requests. It can also improve user experience and conversion through faster pages. Conversely, a cache that is oversized, rarely hit, or holding data nobody reads is pure waste. The hit ratio is the cleanest measure of whether the money is working.

A few patterns appear again and again in healthy systems, and a few traps appear in broken ones.

Patterns that work well

Anti-patterns to avoid

Memorystore is one of several ways to make data fast, and each way fits different needs.

How to choose

Start with the question: what is slow, and why? If a database is overloaded by repeated identical reads, a cache helps. If web pages are slow because users are far away, a content delivery network helps. If a very small set of values is read constantly inside one process, an in-process cache is enough. If many servers need to share fast state, such as sessions and counters, a shared in-memory store is the right tool. Often the best design combines two or three of these layers.

A short checklist makes the difference between a trusted cache and a source of incidents.

Best practices

Common mistakes

Concrete stories show how the ideas fit together under real traffic.

Short answers to the questions engineers ask most when adopting Memorystore.

Choose Memcached for simple, disposable string caching. Choose a Redis or Valkey offering when you need rich data structures, persistence options, or replication. Choose a clustered offering when you expect large scale or high throughput. Confirm current feature support in the documentation.

It is generally not recommended, because memory is volatile and costly. If you do store important state, use a replicated tier with persistence and regular exports, and test restoring. For most designs, keep the system of record in a durable database.

No. Instances have private addresses and are reachable only through connected private networks. Use a VM in the network, a VPN, or another private path for access.

In replicated tiers, the replica is promoted automatically, and clients reconnect to the same endpoint after a brief interruption. A tiny amount of the latest writes may be lost because replication is asynchronous. A single-node tier loses its data and is unavailable until it recovers.

Add random variation to TTLs, let only one request rebuild an expired entry while others wait or use the old value, and refresh very popular entries before they expire.

Common causes are TTLs that are too short, keys that include changing values so entries are never reused, an instance too small so entries are evicted, or caching data that is rarely requested twice. Examine key design and eviction metrics.

Yes, provided they have a private network path into the instance’s network, using direct VPC egress or a connector. Keep them in the same region to avoid extra latency.

No. Replication is typically asynchronous, so reads from replicas can be slightly stale. Use replica reads only where small staleness is acceptable.

Leave meaningful headroom, since replication buffers, snapshots and memory overhead need space. Do not size an instance to exactly match your data, and set alerts well before the limit.

Ask what happens if the cache is empty right now. If the answer is a short period of slower responses, the design is sound. If the answer is a crisis, add a fallback, protect the database, or reconsider what you are storing.

Memorystore gives you managed, very fast in-memory data on open source engines. It shields databases from repeated reads, shares fast state such as sessions and counters across many servers, and supports real-time features like leaderboards and rate limiting. Google handles provisioning, patching and failover, while you decide the engine, tier, size, eviction behavior and the caching pattern.

The craft lies in respecting what memory is: fast, limited and forgetful. Keep a durable source of truth, set expiry on cached data, choose an eviction policy deliberately, run replicated or clustered setups in production, and avoid hot keys, big keys and heavy commands. Watch hit ratio, evictions and memory, rehearse failure, and keep applications close to the instance. Done well, Memorystore turns slow, expensive requests into instant answers.