First, a quick look at why memory is special, and what the service actually is.

Memory versus disk

A computer keeps data in two kinds of places. A disk is large and cheap, and it remembers things even when the power is off, but it is slow. Memory (also called RAM) is small and costly, and it forgets everything when the power goes off, but it is incredibly fast, often thousands of times quicker than a disk.

An in-memory data store keeps its data mainly in memory, so reads and writes finish in a tiny fraction of a second, often well under a millisecond. That is the secret of Memorystore.

The service in one sentence

Memorystore is a fully managed in-memory data service in Google Cloud. It runs popular open-source engines, so your applications can use tools and libraries they already know, while Google handles the servers, patching, monitoring, and failover.

The family of engines

• Memorystore for Redis: the classic managed Redis, with a primary machine and an optional standby copy.
• Memorystore for Redis Cluster: a bigger, sharded Redis design that spreads data across many machines for huge scale.
• Memorystore for Valkey: a managed service for Valkey, an open-source engine that began as a community continuation of Redis and speaks a very similar language.
• Memorystore for Memcached: a simple, very fast cache that stores plain key-and-value items.

The pain it removes from application builders.

The slow database problem

Most apps keep their important data in a database. Each time a user opens a page, the app asks the database questions. If a million people ask the same question, such as “what are today’s top products?”, the database repeats the same hard work a million times. It gets slow, then busy, then it may fall over.

The cache idea

A cache is a quick-access copy of data that is expensive to fetch. The app asks the cache first. If the answer is there, called a cache hit, the app responds at once. If not, called a cache miss, the app asks the database, then saves the answer in the cache for next time.

flowchart LR
  U["User request"] --> APP["Application"]
  APP --> C{"Is the answer in Memorystore?"}
  C -- "Hit: fast answer" --> APP
  C -- "Miss" --> DB["Database: slower"]
  DB --> APP
  APP -- "Save for next time" --> M["Memorystore"]
    

Why not run Redis yourself?

You could install Redis on a virtual machine. Then you would need to patch it, watch its memory, plan backups, build a standby machine, and detect failures at 3 AM. A managed service does that work for you.

These words appear everywhere. Learn them once.

Key and value

An in-memory store like Redis holds data as key-value pairs. The key is a name, such as “user:42:profile”. The value is the data stored under that name. To find something, you ask for its key, like looking up a word in a dictionary.

Data structures

Redis and Valkey do more than store plain text. They offer ready-made shapes for data:

• Strings: a single piece of text or number, such as a page counter.
• Hashes: a small record with named fields, like a user’s name, city, and age.
• Lists: an ordered line of items, handy for queues.
• Sets: a bag of unique items, such as “users online right now”.
• Sorted sets: items ranked by a score, perfect for leaderboards.
• Streams and pub/sub channels: ways to send messages between programs.

TTL (time to live)

A TTL is a countdown timer you attach to a key. When it reaches zero, the item is deleted automatically. TTLs stop old data from sitting around forever and keep the cache fresh.

Eviction

Memory is limited. When it fills up, the store must decide what to throw away. This is called eviction. A common rule is “remove the least recently used items first”. You choose the rule, called the eviction policy, to match your needs.

Instance, node, shard, replica

• Instance: one Memorystore deployment that you create and name.
• Node: one machine holding part or all of the data.
• Shard: one slice of the data in a cluster, so that many nodes share the load.
• Replica: a live copy of data kept on another node for safety and extra read capacity.

The biggest decision at the start of a project.

flowchart TD
  Q1{"Need data types, persistence, or messaging?"} -- "No, plain cache" --> MC["Memcached"]
  Q1 -- "Yes" --> Q2{"Dataset or traffic larger than one machine?"}
  Q2 -- "Yes" --> CL["Redis Cluster or Valkey"]
  Q2 -- "No" --> Q3{"Must stay up if a zone fails?"}
  Q3 -- "Yes" --> ST["Redis Standard tier"]
  Q3 -- "No" --> BA["Redis Basic tier"]
    

Redis versus Memcached in plain words

Memcached is a straightforward cache. It is easy and fast, but it forgets everything if a machine restarts, and it only knows key-and-value text or bytes. Redis and Valkey are richer. They support many data shapes, can keep copies for safety, can save data to disk in some setups, and can handle messaging. If you are unsure, the Redis family is the usual starting point, because it can do everything Memcached can and more.

How the pieces fit together inside Google Cloud.

The main pieces

• Your application: a program on Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, or Cloud Functions that uses a normal Redis, Valkey, or Memcached client library.
• The Memorystore instance: the managed nodes that hold your data in memory.
• A private network connection: Memorystore has a private IP address, reached through your VPC network, usually via a feature such as private services access or Private Service Connect, depending on the product.
• The management plane: the console, command line, and API used to create, scale, and delete instances.
• Monitoring and logging: metrics and audit logs sent to Cloud Monitoring and Cloud Logging.
• Backing storage for backups: Cloud Storage can hold exported snapshots.

flowchart LR
  subgraph Apps["Your applications in your VPC"]
    GCE["Compute Engine"]
    GKE["GKE Pods"]
    CR["Cloud Run through VPC connector or direct egress"]
  end
  subgraph MS["Memorystore"]
    P["Primary node"]
    R["Replica node in another zone"]
  end
  GCE -- "Private IP" --> P
  GKE -- "Private IP" --> P
  CR -- "Private IP" --> P
  P -- "Replication" --> R
  P --> MON["Cloud Monitoring and Logging"]
  P --> GCS["Cloud Storage exports"]
    

No public internet address

Memorystore is designed to be reached from inside your private Google Cloud network. By default it has no public internet address. If something outside, like your office, must reach it, you need a private route such as a VPN or interconnect. Keep this in mind when you test from a home laptop, as it will not connect directly.

Same region matters

Place your Memorystore instance in the same region as your application, and in a nearby zone if possible. A cache that is far away loses its main advantage: speed.

What happens during a read, a write, and a failure.

Reading and writing

The app opens a connection to the instance’s private address and sends simple text commands, such as “set this key” or “get that key”. The engine finds the key in memory using an efficient lookup structure, and replies almost instantly. Most engines handle commands on a single main thread to keep things simple and quick, which means one very slow command can delay others behind it. That is why choosing the right commands matters.

Replication

In tiers with a replica, every write on the primary is also sent to the replica, usually in the background. This is called asynchronous replication. It is fast, but it means that in a rare failure, the last few writes might not have reached the replica yet.

Failover

Failover means switching to the standby when the primary breaks. In a managed tier, the service notices the failure, promotes the replica to be the new primary, and keeps the same connection address so your app reconnects without a new setup. The app should be written to retry connections after a short break.

sequenceDiagram
  participant A as Application
  participant P as Primary node
  participant R as Replica node
  participant S as Memorystore control plane
  A->>P: Write key and value
  P-->>A: OK
  P->>R: Copy the write in the background
  Note over P: Primary fails
  S->>R: Promote replica to primary
  A->>R: Reconnect and continue
  R-->>A: OK
    

Sharding in a cluster

In a cluster design, the key space is cut into many small buckets called slots. Each shard owns some slots. When you store a key, the engine runs a math formula on the key’s name to decide which slot, and therefore which shard, owns it. This spreads the load. The client library learns the map and sends each command straight to the right shard.

Persistence in plain words

Memory forgets on restart, so some options can save data to disk. A snapshot stores a point-in-time picture of the data. A log of changes records each write so the data can be rebuilt. Which options exist depends on the product and tier, so check the current docs. Even with persistence, treat Memorystore as a speed layer, and keep the official copy of important data in a real database.

How applications and caches work together.

Cache-aside (lazy loading)

The app checks the cache first. On a miss, it reads from the database, saves the result in the cache, and returns it. This is the most common pattern. It is simple and only caches what is actually requested. The downside is that the first request is slow, and the cache can become stale if the database changes.

Write-through

Every time the app writes to the database, it also writes to the cache at the same moment. The cache is always fresh, but every write costs a little more, and the cache may fill with items nobody reads.

Write-behind

The app writes to the cache first, and a background process saves to the database later. Writes are very fast, but if the cache fails before the data is saved, it can be lost. Use it with great care.

Read-through

The app only talks to the cache layer. The cache layer itself fetches from the database on a miss. This hides complexity, but usually needs extra library support.

Keeping the cache fresh

• Use TTLs so old data expires by itself.
• Delete the cached key whenever the database record changes.
• Add small random time to TTLs so many keys do not all expire in the same second.

Making a fast service stay fast under load.

What affects speed

• Distance: keep the app and cache in the same region and close zones.
• Command choice: a command that scans millions of items can block everything behind it. Prefer small, direct commands.
• Value size: huge values take longer to move. Keep them small, and break big objects into smaller pieces.
• Connections: opening a new connection for every request wastes time. Reuse connections with a pool.
• Memory pressure: when memory is nearly full, eviction work and slowdowns begin.

Ways to scale

• Scale up: choose a bigger memory size. Some products allow resizing without rebuilding.
• Scale out: use a cluster and add shards to spread data and traffic.
• Add read replicas: allow reads to be served by replicas when slightly older data is acceptable.
• Cache smarter: store only what truly saves time or money.

Hot keys

A hot key is one item that gets a huge share of all traffic, for example the data of a celebrity’s profile. In a cluster, that key still lives on one shard, so that shard can be overloaded while others sit idle. Fix it by caching a copy inside the application, or by splitting the key into several copies with slightly different names.

Staying up, and getting back up.

High availability

High availability means “the service keeps running even if a part breaks”. Memorystore reaches this by placing a replica in a different zone from the primary, and by promoting it automatically if the primary fails. Cluster designs also spread shards and replicas across zones. Single-node basic setups have no such protection and can be unavailable during maintenance or failure.

Maintenance windows

Google must sometimes update the software or hardware beneath your instance. You can usually choose a preferred maintenance window, a quiet time of week, so these updates do not collide with your busiest hours. Write your application to handle short reconnects gracefully.

Backups and exports

Depending on the product, you can export a snapshot of the data to Cloud Storage and import it into a new instance, or use built-in backup features. Exports help with moving data, creating test copies, and recovering from mistakes.

Think about what loss means

Ask a plain question: “If the whole cache vanished right now, what would happen?” For a pure cache, the answer should be “things get slower for a while, then recover”. For session data, losing it might force users to log in again. For data that cannot be rebuilt, you should keep a real copy elsewhere.

A fast cache full of user data must be protected.

Private networking

Memorystore sits on private IP addresses inside your VPC. Only machines that can reach that network can talk to it. Use firewall rules and network design to allow only the applications that need it.

Authentication

Many setups let you require a secret password, often called an AUTH string, before a client can run commands. Newer cluster products support IAM-based sign-in, which uses Google Cloud identities instead of a shared password. Prefer identity-based access when available, because identities can be revoked and audited.

Encryption

Data at rest is encrypted by Google by default, and customer-managed encryption keys are available on some products. In-transit encryption with TLS protects data as it travels between your app and the cache. Turn it on for sensitive data, and read the current docs for how to enable it on each product.

IAM for management

IAM decides who may create, resize, or delete instances. Give the smallest role that gets each person’s work done. An accidental delete wipes the in-memory data in seconds.

Watch the dashboard lights, and watch the bill.

Key metrics to watch

• Memory usage: if it is close to full, evictions begin and performance changes.
• Cache hit ratio: the share of requests answered from the cache. A low ratio means the cache is not helping much.
• CPU load: high load on the main thread signals slow commands or too much traffic.
• Connected clients: a sudden rise may mean a connection leak in an app.
• Evicted keys and expired keys: show how much data is being pushed out.
• Replication lag: how far behind the replica is.
• Network traffic and command rate: overall load.

Alerts and logs

Set alerts in Cloud Monitoring for memory above a chosen share, for failovers, and for unusual drops in the hit ratio. Audit logs record management actions such as creating or deleting an instance. Some engines also provide slow-command logs to help you find expensive commands.

What drives cost

• Provisioned memory: the main cost. You pay for the size you reserve, not the amount you fill.
• Tier or number of nodes and replicas: replicas and shards add cost.
• Network traffic: moving data across zones or regions can add fees.
• Backups and exports: stored in Cloud Storage with its own charges.

Ways to save

• Cache only the items that are slow or expensive to rebuild.
• Use TTLs, so unneeded data leaves automatically.
• Right-size memory after watching real usage.
• Compress large values before storing them.
• Use the basic tier for easily rebuilt development or test caches.
• Delete unused instances.

An honest report card.

Compared with neighbors

Shapes that work, and traps to avoid.

Good patterns

flowchart TD
  USER["Users"] --> LB["Load balancer"]
  LB --> W1["App server 1"]
  LB --> W2["App server 2"]
  LB --> W3["App server 3"]
  W1 --> MS["Memorystore: sessions, counters, cached pages"]
  W2 --> MS
  W3 --> MS
  W1 --> DB["Main database"]
  W2 --> DB
  W3 --> DB
    

Anti-patterns

Your checklist for the first real project.

Best practices

• Start with the goal. Decide whether you need a cache, a session store, a queue, or all three.
• Choose the tier by the cost of downtime, not just by price.
• Co-locate the instance and the apps in the same region.
• Name keys clearly with a consistent pattern, such as “app:type:id”.
• Always set TTLs and plan how stale data is cleaned.
• Use connection pools and handle reconnects and retries in your client code.
• Turn on authentication and in-transit encryption for anything sensitive.
• Test failover in a safe environment so you know how your app behaves.
• Load-test with realistic traffic before launch.
• Set alerts for memory, hit ratio, and failovers.

Common mistakes

Where in-memory speed pays off.

The common thread: the data is read very often, answers are needed in milliseconds, and the official copy lives safely elsewhere.

You started with a chef who wanted the most-used spices on a shelf by the stove. You now understand that Memorystore is Google Cloud’s managed version of that shelf: fast, reliable, and ready to use.