Topologies
The tier decides how many nodes an instance runs, what happens when one fails, and — the one product fact that reaches your code — which client driver your application needs. Pick the smallest tier that meets your availability and capacity requirements.
The tier decides how many nodes an instance runs, what happens when one fails, and — the one product fact that reaches your code — which client driver your application needs. Pick the smallest tier that meets your availability and capacity requirements.
The three tiers
| Tier | Nodes per region | Failover | Client requirement |
|---|---|---|---|
| Single | 1 | None | Any Valkey or Redis client |
| Highly Available | 3 (standard) or 5 (hardened) | Automatic, within seconds | Sentinel-aware driver |
| Sharded | 6 (standard) or 9 (hardened) at 3 shards, growing with shards | Automatic, per shard | Cluster-aware driver |
Single
One node. The simplest and cheapest tier, and the only one with no driver requirement beyond a standard client.
- For a store instance, a restart recovers by replaying the data from disk — data survives, but the instance is briefly unavailable while it does.
- For a cache instance there is no persistence, so a restart starts empty.
Choose single when the data is rebuildable from another source of truth (a cache backed by your database), or when brief unavailability is acceptable.
Highly Available
A primary with replicas, coordinated by Sentinel. Every node participates in monitoring; when the primary fails, the remaining nodes agree and promote a replica automatically — typically within seconds, with at most the last moments of unsynchronised writes at risk.
The size axis controls failure tolerance:
standard— 3 nodes. Survives the loss of one node.hardened— 5 nodes. Survives the loss of two nodes. It costs nodes and nothing else — the memory you configure applies per node.
Your application needs a Sentinel-aware client driver so it follows the promotion instead of reconnecting to a demoted node. Most mainstream Redis client libraries support Sentinel; it is a connection-configuration change, not a code rewrite.
Choose HA when the working set fits in one node's memory and you need the instance to ride through node failures without an operator.
Sharded
A cluster that partitions the keyspace across shards, each shard being a primary with its own replicas. Capacity and throughput grow with shards; failover happens independently per shard.
standard— 1 replica per shard: 3 shards × 2 nodes = 6 nodes.hardened— 2 replicas per shard: 3 shards × 3 nodes = 9 nodes.
Sharded instances start at 3 shards. Shards only grow in self-service — raising the count is automated, while shrinking requires resharding the keyspace and is handled through a support ticket.
Your application needs a cluster-aware client driver, and there is one design consequence to plan for from the start: multi-key commands and transactions only work when every key involved lives in the same slot. Use hash tags ({user:42}:profile, {user:42}:sessions) in your key schema for keys that must be operated on together.
Choose sharded when the working set will exceed a single node's memory, or when you need write throughput beyond one primary.
Choosing, quickly
| Question | Answer |
|---|---|
| Rebuildable cache, occasional cold start acceptable? | Single |
| Needs to survive node failure without waking anyone up? | Highly Available |
| Working set larger than one node's memory (up to 16 GB)? | Sharded |
| Uses multi-key transactions across arbitrary keys? | Single or HA — the cluster restricts cross-slot operations |
| Tighter failure tolerance on either HA or Sharded? | Set size to hardened |
The tier interacts with the purpose but does not depend on it: a cache can be HA (a cold cache may be as bad as an outage), and a store can be single (durability from disk and backups, without paying for replicas).
Multi-region
Whatever the tier, each selected region runs an independent copy of the topology with its own data. There is no replication between regions — the right shape for active-active deployments where each region's containers use their local instance.