Database / Google Memorystore Interview questions

Teams typically put it in front of a slower database such as Cloud SQL or Spanner, or use it directly for sessions, counters, queues and leaderboards.

Google handles VM provisioning, OS and engine patching, replication, monitoring hooks and automatic failover (on tiers that support it). You still own key design, TTLs, eviction policy and client behaviour.

Memorystore currently offers four products: Memorystore for Redis (single-node or primary/replica), Memorystore for Redis Cluster (sharded), Memorystore for Memcached and Memorystore for Valkey.

Redis and Redis Cluster are based on open-source Redis 7.2 and earlier. Valkey is the Linux Foundation fork of Redis and Memorystore supports versions 7.2, 8.0 and 9.0, with 9.1 in preview at the time of writing.

Pick by workload: simple cache with HA means Redis Standard tier, horizontal scale means Redis Cluster or Valkey, and pure multi-threaded key-value caching means Memcached.

Memorystore for Redis is the original managed Redis offering. One instance is a single logical Redis deployment, either a lone node (Basic tier) or a primary with a replica in another zone (Standard tier).

Capacity runs from 1 GB up to 300 GB per instance, and supported versions run from Redis 3.2 through 7.2. Clients connect to a private IP address inside your VPC using private services access.

Because there is only one primary, write throughput is bounded by a single node. When you outgrow that, the usual next step is Memorystore for Redis Cluster.

Memorystore for Redis Cluster is a managed, sharded Redis deployment. Data is spread over many primaries (shards) using Redis Cluster hash slots, so both memory and throughput scale horizontally instead of being capped by one node.

You choose a node type and a shard count, plus zero to five replicas per shard. Replicas are spread across zones and failover is automatic, which is how the service reaches a 99.99% SLA on supported node types.

Shards can be added or removed while the cluster serves traffic. Clients must be Redis Cluster-aware, and the service also offers RDB/AOF persistence, TLS and cross-region replication.

Memorystore for Memcached is a managed cluster of Memcached nodes. You pick the node count, the vCPU and memory per node, and Google runs it inside your VPC.

It is a pure cache: strings only, no persistence, no replication, no built-in data structures. Keys are spread across nodes by the client using consistent hashing, and an auto-discovery endpoint tells the client which nodes currently exist.

If a node is lost, the keys that lived there are simply gone and the application falls back to the database. That makes it a good fit for read-through caching of rebuildable data, but not for sessions or counters you cannot lose.

Memorystore for Valkey is Google's managed service for Valkey, the open-source, Redis-compatible store maintained under the Linux Foundation. It uses a sharded cluster design like Redis Cluster.

Supported versions are 7.2, 8.0 and 9.0 (the default), with 9.1 in preview as of this writing. You can upgrade an instance in place to any newer version, for example 7.2 straight to 9.0.

Each primary can have up to five replicas, instances can be created in the remaining zones if one zone is unavailable, and multiple VPCs can reach one instance through Private Service Connect endpoints. Valkey 9.0 adds hash field expiration.

Memorystore for Redis has two tiers. Basic is a single node with no replica and no SLA. Standard adds a replica in a second zone with automatic failover and a 99.9% availability SLA.

With Basic, any maintenance, scaling operation or node failure flushes the cache, so it suits development or caches that are cheap to rebuild. Standard keeps data through failover because the replica is continuously synced.

The replica exists mainly for high availability. Writes land on the primary and are streamed asynchronously to the replica, which sits in a different zone.

If the primary or its zone fails, Memorystore promotes the replica and the instance keeps serving, normally with the same endpoint IP. The old primary is rebuilt as the new replica.

Because replication is asynchronous, a few of the most recent writes may be lost in an unplanned failover. If you enable read replicas on a Standard instance, the extra replicas can also serve read traffic.

The most common use is a read-through or cache-aside layer in front of Cloud SQL, Spanner or Firestore to cut read latency and database load.

Other frequent uses: session and token storage, rate limiting with atomic counters, leaderboards with sorted sets, job queues with lists or streams, pub/sub fan-out, and real-time feature lookups for ML serving. Redis Cluster also supports vector search for similarity workloads.

It is a poor fit as a system of record unless you accept the durability limits of persistence and asynchronous replication.

You can use the Cloud Console, Terraform or the gcloud CLI. The key choices are name, region, tier, capacity in GB, Redis version and the VPC network the instance attaches to.

gcloud redis instances create session-cache \
  --region=us-east1 \
  --tier=standard \
  --size=5 \
  --redis-version=redis_7_2 \
  --network=default

Make sure the Memorystore for Redis API is enabled and private services access is configured on the VPC. Once the command finishes, gcloud redis instances describe shows the host IP and port (6379 by default) to hand to your application.

Pick the region close to your clients, since cross-region calls add tens of milliseconds. Terraform's google_redis_instance resource expresses the same settings, which keeps instance sizing reviewable in code.

Memorystore for Redis exposes a private IP in your VPC, so clients must run in that network or a connected one: Compute Engine, GKE, Cloud Run or Cloud Functions via Serverless VPC Access or Direct VPC egress, or on-premises over VPN/Interconnect.

From a Compute Engine VM in the same VPC you can test with:

redis-cli -h 10.0.0.3 -p 6379 ping

If AUTH or TLS is enabled, supply the password and CA certificate. There is no public IP, so connecting from a laptop requires a bastion host, VPN or an SSH tunnel through a VM.

Private services access is the VPC peering-based mechanism that lets Google-managed services such as Memorystore for Redis live in a Google-owned VPC yet be reachable from your VPC using internal IP addresses.

You reserve an IP range (for example a /16) in your VPC, then create a private connection to servicenetworking.googleapis.com. Instances are allocated addresses from that range.

Plan the range carefully. If it overlaps with other subnets or is too small, instance creation fails. Peering is non-transitive, so on-premises access needs custom route advertisement.

Each instance gets a discovery endpoint and a data endpoint per node. The cluster client talks to the discovery address first to learn the topology, then connects to node endpoints directly.

One benefit is that several VPCs, even in different projects, can create PSC endpoints to the same instance, and no IP range overlap with Google's network has to be negotiated.

When memory reaches maxmemory, Redis follows the configured maxmemory-policy. Memorystore for Redis lets you set it to one of these:

The default is volatile-lru. For a pure cache, allkeys-lru is usually safer because keys without a TTL can still be evicted. For data you cannot lose, use noeviction and alert on memory usage.

A single Memorystore for Redis instance can be sized from 1 GB up to 300 GB. Bandwidth and throughput scale with the capacity you pick, because network egress limits are tied to instance size.

Redis itself runs commands on one main thread, so even a big instance is limited by single-node CPU. If you need more than 300 GB, or more throughput than one node gives, move to Memorystore for Redis Cluster or Valkey, which shard data across many nodes.

AUTH is Redis's password mechanism. When you enable it on a Memorystore for Redis instance, Memorystore generates an AUTH string and every client must send it, for example with AUTH <string> or in the connection URL.

It protects against other workloads in the same VPC that can reach the IP but should not read the data. It does not encrypt traffic. Pair it with in-transit encryption (TLS) if the connection crosses untrusted segments.

Rotating the string is possible but requires coordinating client updates, so keep it in Secret Manager rather than in code.

In-transit encryption wraps client-to-Redis traffic in TLS. You turn it on when you create the instance, since for Memorystore for Redis it generally cannot be switched on later.

After creation you download the server CA certificate and configure your client with it. Clients then connect with TLS (often on the same port) and verify the server certificate.

Expect a small CPU cost for the handshake and encryption, so use connection pooling to avoid re-handshaking on every request.

Verify it end to end with redis-cli --tls --cacert server-ca.pem. A certificate or hostname mismatch is the most common cause of handshake errors.

Memorystore for Redis Cluster and Valkey support both modes as managed features. Persistence helps recover after node loss or restart, but it is not a replacement for backups to Cloud Storage when you need long retention.

In cache-aside (lazy loading) the application owns the cache logic. It checks Memorystore first, falls back to the database on a miss, then writes the result back with a TTL.

def get_product(pid):
    key = f"product:{pid}"
    cached = r.get(key)
    if cached:
        return json.loads(cached)          # cache hit
    row = db.fetch_product(pid)            # cache miss
    r.setex(key, 300, json.dumps(row))     # populate, 5 min TTL
    return row

On updates, either delete the key (simplest and safest) or rewrite it. The pattern tolerates cache loss, since the database stays the source of truth, but stale reads are possible until the TTL expires or the key is invalidated.

Wrap the database call in a lock or request coalescing for hot keys, otherwise many parallel misses can all hit the database together.

A maintenance window is the day and hour you tell Memorystore it may apply updates, such as engine patches or infrastructure upgrades, to your instance.

Pick a quiet period for your traffic. If you set none, Google chooses the time. On Basic tier maintenance flushes the cache, while on Standard tier the replica is updated first and then a failover happens, causing a short disconnect.

Maintenance changelogs and Cloud Logging entries tell you what was applied, and Memorystore can notify you ahead of time so you can plan client retries.

Memorystore publishes metrics to Cloud Monitoring automatically, and logs go to Cloud Logging. You build dashboards and alerting policies on top of them.

Metrics worth alerting on:

Database Center also surfaces recommendations across instances. Use INFO and SLOWLOG from redis-cli for per-command detail.

IAM governs the control plane: who can create, update, delete, import or export instances. Predefined roles include Redis Admin, Redis Editor and Redis Viewer, and Memcached has similar ones.

IAM does not, by itself, decide who can run GET or SET on keys. Data access is controlled by network reachability and by AUTH. For Redis Cluster and Valkey you can additionally use IAM-based authentication for clients, so no static password has to be shared.

Follow least privilege: give application service accounts only the access they need and keep admin roles for the platform team.

Every shard in a cluster uses the same node type, which fixes the memory and vCPUs per node. The main types are redis-shared-core-nano, redis-standard-small, redis-highmem-medium, redis-highmem-xlarge and redis-highcpu-medium.

The nano type targets tiny workloads and has no SLA, so keep it out of production. Standard-small allows small clusters and small growth steps. Highmem types give more RAM per core for large datasets, while highcpu gives more compute per GB.

You can change the node type after creation, which lets you right-size as the workload grows.

A shard is one primary node plus its replicas. Each shard owns a slice of the 16,384 hash slots, and each key belongs to exactly one slot, so it lives on exactly one shard.

More shards mean more total memory, more CPU and more connections. Replica count is configured per cluster, from zero to five replicas per shard, and each shard's nodes are spread across zones.

Adding or removing shards triggers slot migration in the background while the cluster keeps serving requests.

Both run Redis-compatible engines, but they scale differently. The classic product is one primary with an optional replica, while the cluster product shards data across many primaries.

Choose the classic product for simple caches that fit on one node. Choose the cluster product when you need more memory, more throughput or a higher availability target.

Redis does more and offers failover, so it is the default choice. Memcached is simpler and uses every core on a node, which suits large volumes of small, disposable cache entries.

Memcached loses a node's data on failure, so only store things the database can rebuild.

A practical rule: if you ever think "I wish I could increment this atomically" or "I need this to survive a restart", you already need Redis, not Memcached.

A health monitor watches the primary. If it stops responding, or its zone fails, Memorystore promotes the replica to primary, then creates a new replica in the freed zone.

sequenceDiagram
    participant C as Client
    participant P as Primary (zone A)
    participant R as Replica (zone B)
    participant M as Memorystore monitor
    C->>P: writes
    P-->>R: async replication
    M->>P: health check fails
    M->>R: promote to primary
    C->>R: reconnect, same endpoint IP
    M->>P: rebuild as new replica

The primary endpoint IP stays the same, so clients just reconnect. Writes accepted by the old primary but not yet replicated can be lost. You can also trigger a manual failover to test your clients, with a limited-data-loss or force-data-loss mode.

Clients should use short connect timeouts, retry with backoff, and reopen pooled connections after a failover, otherwise they keep writing to sockets that point at the dead node. Failover typically completes within about a minute, but test your own app rather than assuming.

Availability comes from three things: replicas, zone spreading and automatic failover. Each shard can have replicas placed in different zones, so one zone outage doesn't take out a whole shard.

When a primary fails, the cluster promotes one of its replicas and updates the topology that clients see. No manual action is needed, and clients with proper cluster logic refresh their slot map after a redirect.

Replicas, AOF/RDB persistence and cross-region replication stack on top for recovery and disaster recovery. The 99.99% SLA assumes at least one replica per shard on supported node types.

Also check that your client sends reads only where you intend. A replica read right after a failover can briefly see older data, so keep read-your-own-write paths on the primary.

You can resize an instance (up or down) with gcloud redis instances update --size. The capacity change is applied by Memorystore, not by you.

On Basic tier, scaling flushes all data and the instance is unavailable for a short time. On Standard tier, the replica is scaled first and a failover follows, so there is only a brief interruption and data is preserved.

Even on Standard tier, run scaling during low traffic and make sure clients retry on connection errors. Shrinking requires that the new size can hold the current dataset.

Scaling also changes bandwidth and throughput limits, since both depend on instance size, so a resize can fix network-bound latency even when memory is not the bottleneck.

When you change the shard count, Memorystore moves hash slots between shards in the background. The keys in each moving slot are migrated while the cluster keeps answering requests.

flowchart LR
    A["Add shard"] --> B["New shard joins, owns no slots"]
    B --> C["Pick slots to move"]
    C --> D["Migrate keys slot by slot"]
    D --> E["Update slot map"]
    E --> F["Clients get redirected"]

During migration a client may get a MOVED or ASK redirect, which cluster-aware clients handle on their own. Expect a little extra latency for keys in transit. Scale out ahead of load, not in the middle of a spike.

Track progress in the operation status shown by gcloud or the Console. If a cluster is already close to its memory limit, scale earlier, because the migrating keys briefly exist on both sides.

Choose Redis Cluster when your dataset or throughput will not fit comfortably on a single node, or when you need the 99.99% SLA, zero-downtime scaling and zone-distributed replicas.

Stay on Standard tier when the data is under a few tens of GB, the workload is mostly simple, and your code uses multi-key commands or Lua scripts across arbitrary keys that would be awkward on a sharded layout.

Migrating later means changing the client to a cluster-aware one and reviewing key design, so decide early if growth is likely.

A simple test: estimate peak ops per second and dataset size for the next year. If either approaches the capacity of one node, begin with Cluster and avoid a later migration.

Pick Memcached when the job is purely to cache rebuildable values as plain strings and you want simple horizontal scaling with all cores of each node in use.

Typical fits are HTML fragments, query results and API responses where a lost node just means a temporary drop in hit ratio. If you need persistence, replication, atomic counters, sorted sets, streams or pub/sub, choose a Redis-compatible product instead.

Remember that Memcached sharding happens in the client, so every service must use the same hashing configuration and the auto-discovery endpoint.

Memcached also tolerates adding nodes easily, though consistent hashing means only a fraction of keys move and the rest stay put. Test the hit-ratio dip when you resize.

On Standard tier you can enable read replicas, which adds up to five replicas in total and a separate read endpoint. The read endpoint spreads connections across the replicas.

Writes still go to the primary endpoint. Replication is asynchronous, so a read replica may return slightly old data. Treat it as eventually consistent: good for product catalogs, not for balance checks.

The point is to offload read-heavy traffic from the primary and to have more failover candidates. Remember that enabling read replicas is an instance-level setting that affects pricing and can't simply be toggled off at will.

Use the read endpoint only for paths where staleness is acceptable, and monitor replication lag so a lagging replica doesn't serve very old values.

The client starts from the instance's discovery endpoint, a PSC address that returns the current cluster topology. It asks for the slot-to-node mapping (for example with CLUSTER SLOTS) and keeps it in memory.

From then on, it hashes each key, looks up the owner node endpoint and sends the command there directly. If the topology changes, a MOVED reply makes the client refresh its map.

from redis.cluster import RedisCluster
rc = RedisCluster(host="10.1.0.5", port=6379)   # discovery endpoint
rc.set("user:42:name", "Asha")
print(rc.get("user:42:name"))

Don't hard-code individual node IPs, since replicas and primaries swap roles during failover.

Most cluster clients also re-run discovery periodically and on connection failures, so a node replaced by Memorystore is picked up without an application restart.

Redis applies the configured maxmemory-policy. With an eviction policy such as allkeys-lru, it removes keys to make room for each new write, so the evicted-keys metric climbs and hit ratio drops.

With noeviction, writes that need more memory fail with an OOM error while reads keep working. Applications that don't handle that error can start failing in odd ways.

Memory fragmentation and replication buffers also consume RAM beyond the dataset, so alert well before 100% usage. The fix is a bigger instance or more shards, shorter TTLs, smaller values or a more selective eviction policy.

Check that the application handles the OOM error and does not retry in a tight loop, since that adds load to an already full instance.

Start by separating server time from network and client time. Run redis-cli --latency from a VM in the same zone and compare it with what the app sees.

Then check the usual suspects in order:

1. CPU near 100% on the primary, since Redis is mostly single-threaded.
2. SLOWLOG GET for O(N) commands such as KEYS, SMEMBERS on huge sets or large LRANGE calls.
3. Big keys that block the thread while being read or deleted (use UNLINK instead of DEL).
4. Memory at the limit, causing constant eviction work.
5. Connection storms or missing pooling that add handshake overhead.
6. Cross-zone or cross-region client placement.

Fix the cause: replace KEYS with SCAN, split big keys, add shards or replicas for reads, and keep clients in the same region.

Because the keyspace is split across shards, a node only answers for the slots it owns. For any other key it replies with a MOVED redirect. A plain client doesn't follow redirects and would just see errors.

A cluster-aware client loads the slot map, computes CRC16(key) mod 16384 locally and sends each command to the right node. It also refreshes the map after failover or resharding and splits pipelines per node.

Examples include redis-py's RedisCluster, Jedis/Lettuce cluster mode and ioredis Cluster. Multi-key commands only work when every key maps to the same slot, which you can force with hash tags.

Memorystore for Redis can export an RDB snapshot of an instance to a Cloud Storage bucket and import an RDB file from a bucket into an instance.

gcloud redis instances export gs://my-bucket/cache.rdb my-cache --region=us-east1
gcloud redis instances import gs://my-bucket/cache.rdb my-cache --region=us-east1

The instance's service account needs access to the bucket. An import replaces what is in the target instance, and during an import the instance is not available for normal use, so schedule it. On Standard tier, export is taken from the replica path to limit impact on the primary, but plan for a short latency bump anyway.

This is also the simplest backup method: export on a schedule with Cloud Scheduler and keep files under a bucket lifecycle rule.

The right method depends on how much downtime and data loss you can tolerate.

For a pure cache, many teams skip data copy altogether and just let the new instance warm up. For a store with real data, use RDB import plus a live sync, check key counts and sample values, switch clients, then retire the old deployment.

Check version compatibility first: Memorystore supports Redis 7.2 and earlier, so a newer source may use features or RDB formats it cannot load.

Cross-region replication links a primary cluster in one region to one or more secondary clusters in other regions. Writes go to the primary and are copied asynchronously to the secondaries, which are read-only.

flowchart LR
    App1["App in region A"] -->|reads and writes| P["Primary cluster, region A"]
    P -->|async replication| S["Secondary cluster, region B"]
    App2["App in region B"] -->|reads| S

It serves two purposes: regional disaster recovery and low-latency reads close to users in other regions. In a regional outage you can switch the roles so a secondary becomes the primary.

Because the link is asynchronous and crosses regions, expect some replication lag and possible loss of the latest writes on an unplanned failover.

Test the switchover regularly. A DR plan that was never exercised often fails on DNS, client config or capacity in the secondary region, not on Redis itself.

By default Memorystore encrypts data at rest with Google-managed keys. With CMEK (customer-managed encryption keys) you instead point the instance at a key you control in Cloud KMS.

You create the key and key ring, grant the Memorystore service agent the cloudkms.cryptoKeyEncrypterDecrypter role on it, then reference the key when creating the instance. The key location must match the instance region.

If you disable or destroy the key, the service can no longer decrypt the persisted data, so treat key lifecycle as part of your operations. CMEK helps meet compliance rules but doesn't replace TLS or AUTH.

Audit access with Cloud Audit Logs on the key, and use separate keys per environment so that disabling a test key never touches production data.

Think in layers, since no single feature covers everything:

1. Network: keep the instance on private IPs only, restrict who can reach the VPC or PSC endpoint with firewall rules, and consider VPC Service Controls.
2. Authentication: enable AUTH (or IAM auth on cluster products) and store secrets in Secret Manager.
3. Encryption: turn on TLS for in-transit traffic and use CMEK where policy requires.
4. Access control: use least-privilege IAM roles for managing instances.
5. Visibility: enable audit logs and alert on unusual client counts.

Some options, such as in-transit encryption, are chosen at creation time, so decide before launch, not after.

Also run Redis commands with least privilege: on cluster products with ACL or IAM auth, avoid giving application users administrative commands like FLUSHALL and CONFIG.

Cost is driven by provisioned capacity, node count and tier, not by how much of it you use, so right-sizing is the main lever.

1. Use Basic tier or a smaller node type in dev and test.
2. Size from the working set plus headroom, using memory usage and hit ratio metrics, then shrink if you are far below.
3. Use shorter TTLs and compression so fewer GB are needed.
4. Pick replicas by need: zero replicas for rebuildable caches in Cluster, one or more for critical data.
5. Buy committed use discounts for steady production usage.
6. Delete idle instances and use deletion protection only where required.

Always compare saved cost against the extra database load a smaller cache will cause.

Review the bill monthly alongside the hit-ratio chart. A cache with a 20% hit ratio is usually costing money without saving much database load.

Redis stores every key plus overhead, so small design choices add up at millions of keys.

1. Use short, consistent key names.
2. Pack small related fields into hashes, which use compact encodings below size thresholds.
3. Set TTLs so stale data leaves on its own.
4. Compress large values (for example gzip or snappy) on the client.
5. Avoid huge keys; split them into buckets.
6. Pick integer IDs over long UUID strings where possible.
7. Check usage with MEMORY USAGE key and --bigkeys.

Also leave headroom for fragmentation and replication buffers by not running memory at 100%.

For example, storing 1 million small user records as 1 million separate keys costs far more RAM than bucketing them into hashes of a few hundred fields, because each top-level key carries its own overhead.

A TTL gives every cached value a lifetime, so stale entries expire by themselves and memory is reclaimed without any cleanup job.

It also bounds how stale a read can be, which is your effective consistency window in cache-aside. Without TTLs, a missed invalidation can serve wrong data forever, and the instance slowly fills until eviction or OOM errors start.

Pick TTLs from how often data changes and how bad staleness is, and add a little random jitter so many keys don't expire at the same instant. Note that volatile-* eviction policies can only evict keys that have a TTL.

For data like feature flags, a short TTL of a few seconds still gives most of the benefit while keeping changes visible quickly.

All the requests for those keys miss at once and hit the database together. This is a cache stampede (thundering herd), and it can overload the backend exactly when it is least ready.

Ways to reduce it:

1. Add random jitter to TTLs so expiries spread out.
2. Use a short lock (SET lock:key 1 NX EX 10) so one request rebuilds the value while others wait or serve stale data.
3. Refresh hot keys early in the background.
4. Keep a stale copy with a longer TTL as fallback.
5. Rate-limit or queue database access.

Warm the cache after a restart or failover on Basic tier too, since it comes back empty.

Log the miss rate per key prefix. A sudden synchronized spike after a deploy or a restart is the signature of a stampede, not of a general traffic increase.

For most teams Memorystore wins, because patching, failover, monitoring hooks, backups and networking are handled for you, and the SLA comes with the service.

Self-managed makes sense if you need a newer Redis version, custom modules or kernel-level tuning that Memorystore doesn't allow. Count engineer time and on-call risk before deciding it is cheaper.

A hybrid is also common: Memorystore in production for reliability, and a containerized Redis on a developer laptop or CI for fast local tests.

Both are sharded, PSC-connected and highly available, so the choice is mostly about engine and roadmap. Redis Cluster follows open-source Redis 7.2 and earlier, while Valkey is the community-governed fork with active releases (9.0 as default, 9.1 in preview).

For new projects Valkey is the forward-looking choice. Stay on Redis Cluster if you depend on a feature only offered there, such as a specific module or API, and check the current docs for gaps before committing.

Redis Cluster divides the keyspace into 16,384 hash slots. For every key the slot is CRC16(key) mod 16384. Each primary owns a range of slots, for example 0-5460, 5461-10922 and 10923-16383 in a three-shard cluster.

flowchart TD
    K["key: user:42"] --> H["CRC16 mod 16384 = slot 8123"]
    H --> L{Which shard owns slot 8123?}
    L --> S2["Shard 2 primary"]
    S2 --> RR["Replicas of shard 2"]

If the key contains hash tags in braces, only the part inside the first braces is hashed. That lets related keys share a slot so multi-key commands, transactions and Lua scripts work.

SET {cart:42}:items 3
SET {cart:42}:total 59.90
MGET {cart:42}:items {cart:42}:total   # same slot, allowed

Moving a slot means copying its keys to another primary and then updating ownership. Don't overuse one tag for huge groups, or you create a hot shard.

This design is why a cluster has a hard upper limit of 16,384 primaries in theory. Real clusters are far smaller, and Memorystore sets its own shard limits per node type.

Store each session under a key like sess:<id>, as a string with JSON or as a hash, and set a TTL equal to the session timeout. Refresh it with EXPIRE on activity for sliding expiry.

Because losing sessions logs users out, use Standard tier (or a cluster with replicas) rather than Basic, and enable persistence if you want to survive restarts. Make the session ID unguessable and keep values small.

Choose volatile-lru or volatile-ttl eviction so only expiring session keys are evicted. Stateless services can then share the same store, and a failover costs at most a few recent writes.

r.hset(f"sess:{sid}", mapping={"uid": 42, "role": "admin"})
r.expire(f"sess:{sid}", 1800)   # 30 minutes

Never store raw passwords or secrets in the session; keep only a user ID and the minimum claims, and rotate the session ID after login to prevent fixation attacks.