Redis high availability focuses on ensuring continuous service uptime, preventing data loss, and enabling performance scaling to handle node failures and traffic spikes. The architecture evolves through three progressive patterns: Master-Slave Replication (foundational), Sentinel Mode (enhanced availability), and Redis Cluster (availability plus horizontal scaling). Each pattern addresses specific operational requirements and workload scales.

Key evaluation criteria for high availability implementations:

• Automatic Recovery: Ability to restore service without manual intervention after node failures
• Data Durability: Protection against data loss through redundant copies
• Scalability: Capacity to distribute load across multiple nodes
• Operational Overhead: Complexity of deployment, monitoring, and troubleshooting

Deployment Pattern Deep Dive

Pattern 1: Master-Replica Replication

This fundamental pattern establishes a single master node with multiple replica nodes, implementing a write-master read-replica strategy.

Architecture Fundamentals

• Master Node: Handles all write operations and propagates changes to replicas
• Replica Nodes: Serve read requests, synchronized via the REPLICAOF directive or configuration file

Deployment Configurations

Topology	Resource Allocation	Use Case
Single-Host	One server running master (port 6390) plus 1-2 replicas (ports 6391, 6392)	Development, testing, resource-constrained environments
Multi-Host	Master and replicas distributed across 2+ physical/virtual machines	Non-critical production workloads requiring basic redundancy

Strengths and Limitations

Advantages:

• Minimal setup complexity—configure replicas to point to master
• Read throughput scales by adding replica instances
• Data redundancy protects against single-node failure

Drawbacks:

• Manual failover required—master failure halts all writes until intervention
• No automatic promotion—operators must execute REPLICAOF NO ONE and reconfigure topology
• Write bottleneck—all writes constrained to single master instance

Essential Configuration

### Replica Configuration (redis-replica.conf)
# Network port
port 6391

# Master node location
replicaof 192.168.1.10 6390

# Prevent accidental writes to replica
replica-read-only yes

# Replication synchronization timeout
repl-timeout 90

# Partial resynchronization buffer size
repl-backlog-size 64mb

Pattern 2: Sentinel Auto-Failover System

Sentinel enhances master-replica by adding intelligent monitoring and automatic failover capabilities.

Architecture Components

• Data Plane: Standard master-replica nodes storing data
• Control Plane: 3+ sentinel instances (odd number) monitoring health, orchestrating failover, and notifying clients

Deployment Topologies

Environment	Node Distribution	Recommended For	Risk Factor
Testing	1-2 hosts: master + replica + 3 sentinels (port-separated)	QA environments, internal tools	Single host failure crashes entire cluster
Production	3+ hosts: dedicated master, separate replica(s), independent sentinel hosts	Business-critical applications with moderate write loads	No single point of failure

Failover Mechanism: Three-Phase Process

Phase 1: Individual Failure Detection
Each sentinel independently monitors the master via heartbeat. If no valid response arrives within down-after-milliseconds, the sentinel marks the master as subjectively failed.

Phase 2: Quorum-Based Failure Confirmation
The detecting sentinel queries peers. When quorum sentinels (typically ⌊n/2⌋+1) agree on the failure, the master is declared objectively failed, triggering election.

Phase 3: Leader Election and Promotion
Sentinels elect a leader using a consensus algorithm. The leader:

1. Selects the optimal replica based on priority, replication offset, and node ID
2. Promotes it to master with REPLICAOF NO ONE
3. Reconfigures remaining replicas to sync from the new master
4. Updates client configurations via pub/sub notifications

Configuration Reference

### Sentinel Configuration (sentinel.conf)
# Monitor master with quorum requirement
sentinel monitor production-master 192.168.1.10 6390 2

# Failure detection timeout (30 seconds)
sentinel down-after-milliseconds production-master 30000

# Failover operation timeout (3 minutes)
sentinel failover-timeout production-master 180000

# Prevent split-brain: require 1 replica acknowledgment
sentinel min-replicas-to-write production-master 1

# Maximum replica lag threshold (10 seconds)
sentinel min-replicas-max-lag production-master 10

### Master Configuration (Enhanced Durability)
# Enable AOF with fsync every second
appendonly yes
appendfsync everysec

# Hybrid RDB+AOF persistence
aof-use-rdb-preamble yes

Java Client Integration Example

// Maven Dependency
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>4.4.0</version>
</dependency>

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;

public class SentinelAwareRedisClient {
    private static final String MASTER_GROUP = "production-master";
    private static final Set<String> sentinelAddresses = new HashSet<>(
        Arrays.asList("192.168.1.21:26479", "192.168.1.22:26480", "192.168.1.23:26481")
    );
    
    private static JedisSentinelPool connectionPool;
    
    static {
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        poolConfig.setMaxTotal(128);
        poolConfig.setMaxIdle(30);
        poolConfig.setMinIdle(10);
        poolConfig.setMaxWaitMillis(5000);
        poolConfig.setTestOnBorrow(true);
        
        String password = System.getenv("REDIS_PASSWORD"); // null if no auth
        
        connectionPool = new JedisSentinelPool(
            MASTER_GROUP,
            sentinelAddresses,
            poolConfig,
            password
        );
    }
    
    public static void performOperation(String key, String value) {
        try (Jedis connection = connectionPool.getResource()) {
            connection.setex(key, 3600, value);
            String retrieved = connection.get(key);
            System.out.printf("Stored and retrieved: %s = %s%n", key, retrieved);
            
            // Verify current master
            System.out.println("Active master: " + connection.getClient().getHost());
        } catch (Exception e) {
            System.err.println("Redis operation failed: " + e.getMessage());
        }
    }
    
    public static void shutdown() {
        if (connectionPool != null && !connectionPool.isClosed()) {
            connectionPool.close();
        }
    }
}

Pattern 3: Redis Cluster Sharding

Redis Cluster provides both high availability and horizontal scalability through data partitioning and distributed consensus.

Architecture Design

• Data Partitioning: 16384 hash slots distributed across master nodes
• Replication: Each master maintains 1-N replicas for fault tolerance
• Gossip Protocol: Nodes continuously exchange state information for health monitoring and slot synchronization

Production Deployment Layouts

Scale	Node Distribution	Optimal For
Standard	3 hosts, each running 1 master + 1 replica (ports 7000-7005)	High-traffic applications requiring fault tolerance
Premium	6 dedicated hosts (3 masters + 3 replicas)	Maximum isolation and availability for large datasets

Capabilities and Constraints

Benefits:

• Linear performance scaling—add masters to increase capacity
• Isolated failure impact—single master failure affects only its slots
• Zero-downtime failover—replicas automatically promoted

Considerations:

• Operational complexity—requires slot management and rebalancing
• Client requirements—must use cluster-aware drivers (e.g., Jedis Cluster, lettuce)
• Command limitations—multi-key operations must belong to same slot or use hash tags

Cluster Configuration and Management

### Cluster Node Configuration (redis-cluster-node.conf)
# Enable cluster mode
cluster-enabled yes

# Cluster state file (auto-generated)
cluster-config-file nodes-7000.conf

# Node communication timeout (milliseconds)
cluster-node-timeout 15000

# Persistence
appendonly yes

# TCP backlog for high-throughput
tcp-backlog 511

### Cluster Creation Commands
# Initialize 3-master 3-replica cluster
redis-cli --cluster create 192.168.1.31:7000 192.168.1.32:7001 192.168.1.33:7002 \
                                   192.168.1.31:7003 192.168.1.32:7004 192.168.1.33:7005 \
                                   --cluster-replicas 1

# Check cluster health
redis-cli -c -p 7000 cluster info

# View slot distribution
redis-cli -c -p 7000 cluster slots

# Reshard operation for scaling
redis-cli --cluster reshard 192.168.1.31:7000

Deployment Pattern Comparison Matrix

Characteristic	Master-Replica	Sentinel	Redis Cluster
Fault Recovery	Manual process required	Automatic, seconds-level	Automatic, per-shard recovery
Data Redundancy	Single backup copy	Multiple copies, configurable durability	Per-shard replicas, highest reliability
Write Scalability	Limited to single master	Limited to single master	Linear scaling across masters
Read Scalability	Horizontal via replicas	Horizontal via replicas	Horizontal via replicas and masters
Operational Complexity	Low	Medium (manage sentinels)	High (manage slots, nodes)
Best Use Case	Development, low-traffic caching	Production with moderate write load	High-throughput, large dataset production

Operational Monitoring and Troubleshooting

Essential Monitoring Commands

# General Health Check
INFO server          # Node role and version
INFO replication     # Sync status, lag metrics
INFO memory          # Memory usage patterns
CLIENT LIST          # Active connections

# Sentinel-Specific
SENTINEL masters     # Monitored masters overview
SENTINEL replicas production-master  # Replica details
SENTINEL failover production-master  # Trigger manual failover test

# Cluster-Specific
CLUSTER INFO         # Cluster state and slot coverage
CLUSTER NODES        # Node membership and health
CLUSTER SLOTS        # Slot-to-node mapping

Common Issues and Mitigations

Split-Brain Scenario:
When network partitions cause multiple masters to accept writes, data divergence occurs. Mitigate by setting min-replicas-to-write and min-replicas-max-lag to ensure writes require replica acknowledgment.

Sentinel Failover Stalled:
Verify inter-sentinel connectivity, quorum settings, and replica synchronization status. Review sentinel logs for election conflicts or network timeouts.

Cluster Slot Imbalance:
Use redis-cli --cluster rebalance or manually reshard slots from overloaded nodes. Monitor key distribution to prevent hot spots.

Replica Lag in Read-Heavy Workloads:
Implement application-level tolerance for eventual consistency. For critical reads, use the WAIT command to ensure replication before returning results.

Pattern Selection Guidelines

1. Development/Testing: Master-Replica provides simplicity and adequate functionality.
2. Production (Low/Moderate Load): Sentinel delivers automatic failover without complexity overhead—ideal for most business applications.
3. Production (High Load/Large Data): Redis Cluster enables both read and write scaling essential for high-traffic scenarios.
4. Managed Services: Cloud offerings (AWS ElastiCache, Azure Cache, Google Memorystore) abstract operational complexity for teams prioritizing development velocity.

Implementation Considerations

The progression from master-replica to sentinel to cluster reflects increasing demands for performance and resilience. Regardless of pattern selection, always enable persistence (AOF with RDB snapshots) and establish comprehensive monitoring (Prometheus, Grafana, or Datadog). Test failure scenarios regularly through chaos engineering practices to validate failover behavior and recovery procedures.