Applies toRedis 7.x and Valkey (self-managed), Redis Sentinel, Redis Cluster; Azure Managed Redis, Amazon ElastiCache/MemoryDB, Redis Cloud
Topologies
| Topology | Availability | Scale | App impact |
|---|---|---|---|
| Standalone | Single point of failure | One node's memory/CPU | Simplest |
| Primary + replicas + Sentinel | Automatic failover | Reads can scale to replicas; writes one node | Clients must be Sentinel-aware |
| Redis Cluster | Failover per shard | Data and writes sharded across primaries | Cluster-aware clients; multi-key ops need same hash slot |
| Managed service (non-clustered or clustered) | Provider-managed failover, zone redundancy options | Tiers up to large clusters | Endpoint handles discovery (check client support) |
Decision questions
- Is it a cache or a data store? Losing a cache is tolerable; a data store needs persistence and HA (or consider MemoryDB-like durable services).
- Data size and write throughput? Beyond one node → Cluster.
- Multi-key operations? Transactions, Lua scripts,
MGETacross keys require the same hash slot in Cluster. Use hash tags ({user:42}:cart,{user:42}:profile). - Client libraries: do they support Sentinel/Cluster and reconnect properly on failover?
- Operations: who handles patching, failover testing, memory issues (see the Sentinel failover Sev1 post)?
Typical choices
| Situation | Choice |
|---|---|
| Session/cache store, moderate size, cloud | Managed non-clustered tier with zone redundancy |
| Large cache or high throughput | Managed clustered tier |
| Self-managed, small data, need HA | Primary + 2 replicas + 3 Sentinels |
| Self-managed, large data | Redis Cluster with 3+ primaries, each with a replica |
| Durable primary database on Redis APIs | Service designed for durability; validate persistence guarantees |
Design points
| Area | Recommendation |
|---|---|
| Zones | Replicas in different zones; Sentinel quorum across zones |
| Persistence | Match to role: none/RDB for caches; AOF for data stores (see the Redis standalone post) |
| Memory headroom | Leave room for replication buffers and fork copy-on-write |
| Security | TLS, ACL users per application, private networking |
| Testing | Failover drills under load; client reconnect behaviour |
Tip
Test failover from the application's point of view, not just Redis's. Many outages are clients that cache the old primary's address and never reconnect.
Checklist
- Cache vs data store role decided
- Topology chosen by size, throughput and availability
- Multi-key operations checked for Cluster
- Client libraries verified
- Zones, persistence and headroom designed
- Failover tested from the application