Redis: Data Structures, Persistence, and Clustering - Distributed Cache Systems | OneNoughtOne

0/273

System Design (HLD)Distributed Cache Systems

Distributed Cache Systems

LevelIntermediate

Duration90 mins

TopicDistributed Cache Systems

1 / 5

Redis: Data Structures, Persistence, and Clustering

The Swiss Army Knife of Distributed Data Stores

In the landscape of distributed caching solutions, Redis stands apart—not merely as a cache, but as a sophisticated in-memory data structure server that has fundamentally reshaped how engineers architect high-performance systems. Originally created by Salvatore Sanfilippo in 2009, Redis (Remote Dictionary Server) has evolved from a simple key-value store into a versatile platform supporting complex data types, persistence options, clustering, pub/sub messaging, and even Lua scripting.

What distinguishes Redis from simpler caching solutions is its native support for rich data structures—lists, sets, sorted sets, hashes, streams, and more—each implemented with optimal time complexities that would take significant effort to replicate in application code. This means Redis doesn't just store your data; it provides powerful operations on that data while it resides in memory.

Today, Redis powers caching layers at Netflix, Twitter, GitHub, Stack Overflow, and virtually every major technology company. Its reputation for blazing speed (capable of handling millions of operations per second on modest hardware) combined with operational flexibility has made it the de facto choice for scenarios ranging from session management to real-time analytics to message brokering.

What You Will Learn

By the end of this page, you will understand Redis's core data structures and their algorithmic properties, master the nuances of Redis persistence mechanisms (RDB vs AOF) and their durability trade-offs, comprehend Redis Cluster architecture for horizontal scaling, and develop the expertise to make informed decisions about Redis deployment topologies for various use cases.

Redis Architecture Fundamentals

Before diving into specific features, it's essential to understand Redis's architectural philosophy. Redis achieves its remarkable performance through a set of deliberate design decisions that prioritize speed while maintaining correctness.

Single-Threaded Event Loop:

Contrary to what many engineers initially assume, Redis's core operations run in a single-threaded event loop. This design eliminates the overhead of context switching and locking that multi-threaded systems incur. Because there's only one thread processing commands, operations are naturally serialized—no locks are needed, and there's no risk of race conditions on data structures.

This doesn't mean Redis can't utilize multiple cores. Starting with Redis 6, I/O threading allows multiple threads to handle network I/O while the main thread processes commands. Background threads handle persistence operations, and Redis Cluster distributes load across multiple processes. But command execution remains single-threaded, which is why individual Redis operations are atomic.

Redis Threading Model Evolution
Component	Threading Model	Purpose	Performance Impact
Command Processing	Single-threaded	Atomicity, simplicity, no locks	Predictable latency, ~300K ops/sec per core
Network I/O (Redis 6+)	Multi-threaded (optional)	Handle high connection counts	2-3x throughput improvement
Persistence (RDB)	Background fork	Point-in-time snapshots	Minimal impact on main thread
Persistence (AOF rewrite)	Background fork	Log compaction	Minimal impact on main thread
Lazy object freeing	Background thread	Avoid blocking on large deletes	Instant DEL commands

Memory-First Architecture:

Every piece of data in Redis resides primarily in RAM. This is the source of Redis's sub-millisecond latency—there are no disk seeks involved in reads or writes. The data structures are implemented with memory-efficient representations that automatically upgrade as data grows:

Strings use simple dynamic strings (SDS) with length prefixes
Small lists, sets, and hashes use compact encodings (ziplist, intset, listpack)
Larger collections upgrade to hash tables, skip lists, or quicklists

This automatic encoding optimization means developers get performance benefits without manual tuning in most cases.

Memory Is the Limiting Factor

Since all data must fit in memory, Redis capacity planning is fundamentally different from disk-based databases. Your Redis dataset size is bounded by available RAM (minus overhead for the OS and Redis internals). For datasets larger than available memory, you must either use Redis Cluster to shard across machines or accept that some data will be evicted according to your configured eviction policy.

RESP Protocol (Redis Serialization Protocol):

Redis communicates using a simple, human-readable text protocol called RESP. Commands are sent as arrays of bulk strings, and responses can be strings, integers, arrays, or errors. This simplicity has enabled Redis client libraries in virtually every programming language.

*3\r
$3\r
SET\r
$5\r
mykey\r
$7\r
myvalue\r

Translates to: SET mykey myvalue

The RESP protocol's simplicity keeps parsing overhead minimal, contributing to Redis's low latency characteristics.

Core Data Structures Deep Dive

Redis's power comes from its rich collection of data structures, each providing specific operations with guaranteed time complexities. Understanding these structures—and when to use each—is fundamental to effective Redis usage.

Strings: The Foundation

Redis Strings are the simplest data type but far more versatile than they appear. A String can hold text, serialized objects, binary data (up to 512MB), or numeric values. Redis automatically handles numeric operations on String values:

SET key value — O(1)
GET key — O(1)
INCR key / DECR key — O(1) atomic counter
APPEND key value — O(1) amortized
GETRANGE key start end — O(N) where N is substring length

Common Use Cases:

Session tokens: SET session:abc123 "{user_id: 42, expires: ...}"
Page view counters: INCR page:views:/home
Rate limiting: SET ratelimit:user:42 1 EX 60 NX (set if not exists, 60-second expiry)
Distributed locks: SET lock:resource abc123 EX 30 NX

redis-string-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Basic string operations
SET user:1:name "Alice Johnson"
GET user:1:name                    # Returns: "Alice Johnson"
 
# Atomic counter - thread-safe without locks
INCR article:123:views            # Returns: 1
INCR article:123:views            # Returns: 2
INCRBY article:123:views 100      # Returns: 102
 
# Set with expiration (session management)
SET session:xyz789 "user_data..." EX 3600    # Expires in 1 hour
 
# Conditional set (distributed locking)
SET lock:order:5001 "worker-1" NX EX 30      # Only sets if key doesn't exist
 
# Batch operations (reduces network round trips)
MSET user:1:name "Alice" user:1:email "[email protected]"
MGET user:1:name user:1:email

Lists: Ordered Collections

Redis Lists are doubly-linked lists of strings, optimized for insertion and removal at both ends. They're perfect for queues, recent activity feeds, and bounded collections.

LPUSH key value / RPUSH key value — O(1) per element
LPOP key / RPOP key — O(1)
LRANGE key start stop — O(S+N) where S is offset, N is elements returned
LLEN key — O(1)
LINDEX key index — O(N) for middle elements
BLPOP key timeout — Blocking pop (for queue consumers)

Internal Implementation:

Small lists use listpack (formerly ziplist)—a contiguous block of memory that's cache-friendly. Larger lists upgrade to quicklist—a doubly-linked list of listpacks, balancing memory efficiency with access speed.

redis-list-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Task queue pattern
RPUSH jobs:email '{"to":"[email protected]","subject":"Welcome"}'
RPUSH jobs:email '{"to":"[email protected]","subject":"New signup"}'
 
# Worker consumes from queue (blocking)
BLPOP jobs:email 30               # Blocks up to 30 seconds for item
 
# Recent activity feed (capped at 100 entries)
LPUSH activity:user:42 '{"action":"login","time":"2024-01-15T10:30:00Z"}'
LTRIM activity:user:42 0 99       # Keep only 100 most recent
 
# Get last 10 activities
LRANGE activity:user:42 0 9
 
# Reliable queue with BRPOPLPUSH (atomic move between lists)
BRPOPLPUSH jobs:pending jobs:processing 30   # Move job to processing list

Sets: Unordered Unique Collections

Redis Sets are unordered collections of unique strings. They support fast membership testing and powerful set operations (union, intersection, difference).

SADD key member — O(1)
SISMEMBER key member — O(1)
SMEMBERS key — O(N)
SINTER key1 key2 — O(N*M) where N is smallest set cardinality
SUNION key1 key2 — O(N) sum of all elements
SCARD key — O(1)

Use Cases:

Tag systems: SADD article:123:tags "redis" "caching" "database"
Friend relationships: SADD user:42:friends 101 102 103
Finding mutual friends: SINTER user:42:friends user:101:friends
Unique visitor tracking: SADD visitors:2024-01-15 "ip:1.2.3.4"

Sorted Sets (ZSets): The Workhorse

Sorted Sets are perhaps Redis's most powerful data structure. Each member has an associated score, and the set is automatically sorted by score. This enables leaderboards, time-series windows, rate limiters, and priority queues.

ZADD key score member — O(log N)
ZRANK key member — O(log N)
ZRANGE key start stop [WITHSCORES] — O(log N + M)
ZRANGEBYSCORE key min max — O(log N + M)
ZINCRBY key increment member — O(log N)
ZCARD key — O(1)

Internal Implementation:

Sorted Sets use a skip list for ordered iteration and a hash table for O(1) score lookups by member. This dual-structure design provides the best of both worlds at the cost of additional memory.

redis-sorted-set-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Leaderboard system
ZADD game:leaderboard 1500 "player:alice"
ZADD game:leaderboard 2200 "player:bob"
ZADD game:leaderboard 1800 "player:charlie"
 
# Get top 10 players
ZREVRANGE game:leaderboard 0 9 WITHSCORES
 
# Get player rank (0-indexed)
ZREVRANK game:leaderboard "player:bob"    # Returns: 0 (top position)
 
# Increment score atomically
ZINCRBY game:leaderboard 500 "player:alice"  # Now 2000
 
# Sliding window rate limiter (timestamp as score)
ZADD ratelimit:user:42 1705300000000 "request:abc"
ZREMRANGEBYSCORE ratelimit:user:42 0 1705296400000   # Remove old entries
ZCARD ratelimit:user:42                               # Count in window
 
# Priority queue
ZADD jobs:priority 1 "urgent-job" 5 "normal-job" 10 "low-priority-job"
ZPOPMIN jobs:priority                      # Get highest priority (lowest score)

Hashes: Structured Objects

Redis Hashes are maps between string fields and string values—ideal for representing objects. They're more memory-efficient than storing JSON strings for objects with many fields.

HSET key field value — O(1)
HGET key field — O(1)
HMSET key field1 value1 field2 value2 — O(N)
HGETALL key — O(N)
HINCRBY key field increment — O(1)
HDEL key field — O(1)

Memory Efficiency:

Small hashes (below hash-max-listpack-entries and hash-max-listpack-value) use listpack encoding, which is extremely memory efficient. A user object with 10 fields uses far less memory as a Hash than as a serialized JSON String.

redis-hash-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# User profile as hash
HSET user:42 name "Alice Johnson" email "[email protected]" signup_date "2024-01-15"
HSET user:42 login_count 0 last_active "2024-01-15T10:30:00Z"
 
# Get specific fields (more efficient than HGETALL)
HMGET user:42 name email
 
# Increment counter field
HINCRBY user:42 login_count 1
 
# Get all fields
HGETALL user:42
 
# Check field existence
HEXISTS user:42 premium_tier    # Returns 0 (doesn't exist)
 
# Shopping cart implementation
HINCRBY cart:session:xyz product:123 2    # Add 2 of product 123
HINCRBY cart:session:xyz product:456 1    # Add 1 of product 456
HDEL cart:session:xyz product:123         # Remove product

When to Use Which Structure

• Strings: Simple values, counters, serialized blobs, locks • Lists: Queues, stacks, recent items, activity feeds • Sets: Unique collections, tags, membership testing, set operations • Sorted Sets: Leaderboards, priority queues, time-series, range queries • Hashes: Objects with multiple fields, counters per entity

Advanced Data Types

Beyond the core structures, Redis provides specialized types for specific use cases that would otherwise require complex combinations of basic types.

Streams: Log-Style Data Structure

Introduced in Redis 5.0, Streams provide an append-only log structure similar to Kafka. They support consumer groups for distributing work across multiple consumers, making them ideal for event sourcing, activity feeds, and lightweight message queuing.

Key Operations:

XADD stream-key * field value — Append entry, auto-generate ID
XREAD STREAMS stream-key ID — Read entries after ID
XREADGROUP GROUP group consumer STREAMS stream-key > — Consumer group read
XACK stream-key group id — Acknowledge message processing
XPENDING stream-key group — List pending (unacknowledged) messages

redis-streams-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Event stream for order processing
XADD orders:events * event "order_created" order_id "5001" customer_id "42"
XADD orders:events * event "payment_received" order_id "5001" amount "99.99"
XADD orders:events * event "order_shipped" order_id "5001" tracking "TRK123"
 
# Create consumer group starting from beginning
XGROUP CREATE orders:events fulfillment-workers $ MKSTREAM
 
# Worker reads from group (blocking)
XREADGROUP GROUP fulfillment-workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders:events >
 
# Acknowledge processed message
XACK orders:events fulfillment-workers 1705300000000-0
 
# View pending messages (not yet acknowledged)
XPENDING orders:events fulfillment-workers

HyperLogLog: Probabilistic Cardinality Estimation

HyperLogLog (HLL) is a probabilistic data structure that estimates the cardinality (unique count) of large sets using minimal memory. A single HLL uses only 12KB regardless of how many elements are added, with a standard error of 0.81%.

PFADD key element — Add element(s)
PFCOUNT key — Estimate unique count
PFMERGE destkey sourcekey1 sourcekey2 — Merge HLLs

Use Cases:

Unique visitor counting per page/day
Unique search queries
Distinct IP addresses

redis-hyperloglog-example.txt
1
2
3
4
5
6
7
8
9
10
# Track unique visitors by day
PFADD visitors:2024-01-15 "user:1" "user:2" "user:3" "user:1"  # user:1 counted once
PFCOUNT visitors:2024-01-15                                      # Returns: 3
 
# Merge for weekly count
PFMERGE visitors:week:3 visitors:2024-01-15 visitors:2024-01-16 visitors:2024-01-17
PFCOUNT visitors:week:3
 
# Compare: exact count would require O(N) memory
# HyperLogLog uses fixed 12KB for any N (billions of elements)

Bitmaps: Compact Boolean Arrays

Bitmaps treat strings as bit arrays, enabling extremely memory-efficient storage of boolean values. One million boolean values require only 125KB.

SETBIT key offset value — Set bit at position
GETBIT key offset — Get bit at position
BITCOUNT key [start end] — Count set bits
BITOP AND destkey key1 key2 — Bitwise operations

Use Cases:

User login tracking: Bit per day, bit position = user ID
Feature flags per user
Real-time analytics

Geospatial: Location-Based Queries

Redis Geo commands store longitude/latitude pairs and enable proximity queries. Internally, this uses Sorted Sets with geohash encoding.

GEOADD key longitude latitude member
GEODIST key member1 member2 [km|m|mi]
GEORADIUS key longitude latitude radius unit
GEOSEARCH key FROMMEMBER member BYRADIUS radius unit

redis-geo-example.txt
1
2
3
4
5
6
7
8
9
10
11
# Store restaurant locations
GEOADD restaurants -122.419 37.775 "restaurant:pizza-palace"
GEOADD restaurants -122.421 37.773 "restaurant:burger-barn"
GEOADD restaurants -122.417 37.777 "restaurant:taco-town"
 
# Find restaurants within 1km of coordinates
GEORADIUS restaurants -122.420 37.774 1 km WITHDIST
# Returns: pizza-palace (0.15km), burger-barn (0.14km), taco-town (0.38km)
 
# Distance between two places
GEODIST restaurants "restaurant:pizza-palace" "restaurant:taco-town" km

Persistence: RDB Snapshots

Redis's in-memory nature raises an obvious concern: what happens when Redis restarts? Without persistence, all data is lost. Redis provides two persistence mechanisms—RDB and AOF—each with distinct trade-offs.

RDB (Redis Database) Snapshots

RDB persistence creates point-in-time snapshots of your dataset at specified intervals. The result is a compact, single-file representation of all data that can be used for backups, disaster recovery, or faster restart times.

How RDB Works:

Redis forks the main process using copy-on-write (COW)
The child process writes the dataset to a temporary RDB file
When complete, the temp file atomically replaces the old RDB file
The parent continues serving requests during the entire process

The Fork Operation:

The fork() system call creates a child process with a copy of the parent's memory. Modern operating systems use copy-on-write, meaning pages are only physically copied when modified. This allows the snapshot to capture a consistent view while the parent continues processing writes.

RDB Configuration and Behavior
Configuration	Default	Description
save 900 1	Enabled	Save after 900 seconds if at least 1 key changed
save 300 10	Enabled	Save after 300 seconds if at least 10 keys changed
save 60 10000	Enabled	Save after 60 seconds if at least 10000 keys changed
stop-writes-on-bgsave-error	yes	Stop accepting writes if background save fails
rdbcompression	yes	Use LZF compression for strings in RDB
rdbchecksum	yes	Add CRC64 checksum for corruption detection

redis-rdb-configuration.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# RDB snapshot configuration
# Format: save <seconds> <changes>
save 900 1        # Save after 15 minutes if at least 1 change
save 300 10       # Save after 5 minutes if at least 10 changes
save 60 10000     # Save after 1 minute if at least 10000 changes
 
# Disable RDB entirely (not recommended for production)
# save ""
 
# RDB file location
dir /var/lib/redis
dbfilename dump.rdb
 
# Enable compression (recommended)
rdbcompression yes
 
# Enable checksum verification
rdbchecksum yes
 
# Manual snapshot command
# BGSAVE     - Async background save
# SAVE       - Sync save (blocks server - avoid in production)
# LASTSAVE   - Timestamp of last successful save

RDB Advantages

•Compact single file — Easy to backup, transfer, and version
•Fast restarts — Loading RDB is faster than replaying AOF
•Minimal performance impact — Fork and background write
•Efficient for backups — Point-in-time snapshots ideal for DR
•Disaster recovery — Transfer to remote datacenter easily

RDB Disadvantages

•Potential data loss — Lose data between snapshots on crash
•Fork overhead — Large datasets cause significant fork time
•Write amplification — COW copies entire pages on modification
•Memory spike — During saves, memory usage can double
•Not real-time — Minutes of data loss possible

Fork Latency with Large Datasets

On a Redis instance with 24GB of data, the fork() operation can take 200-500ms, during which Redis blocks all client requests. For datasets approaching 50GB+, fork latency can exceed 1 second. This is particularly problematic on VMs with overcommitted memory. Monitor 'latest_fork_usec' in INFO output to track fork performance.

Persistence: AOF (Append-Only File)

The Append-Only File (AOF) provides durability guarantees closer to traditional databases. Instead of point-in-time snapshots, AOF logs every write operation, enabling recovery by replaying the command log.

How AOF Works

Every write command is appended to the AOF file
Periodically, Redis rewrites the AOF to remove redundant commands
On restart, Redis replays the AOF to reconstruct the dataset

Fsync Policies:

The critical configuration is how often Redis forces the OS to flush the AOF buffer to disk. This determines your durability guarantee:

always — Fsync after every command. Maximum durability, slowest performance.
everysec — Fsync once per second. Balanced approach, recommended.
no — Let the OS decide when to flush. Fastest, but up to 30+ seconds of data loss possible.

AOF Fsync Policies Comparison
Policy	Data Loss Risk	Performance	Recommended For
always	None (one command)	Slowest (10x slower)	Financial transactions, audit logs
everysec	~1 second	Good (slight overhead)	Most production workloads (default)
no	Up to 30+ seconds	Fastest	Ephemeral cache, acceptable loss

redis-aof-configuration.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Enable AOF
appendonly yes
 
# AOF file name
appendfilename "appendonly.aof"
 
# Fsync policy
# always: every command - maximum durability, slowest
# everysec: once per second - recommended balance
# no: OS decides - fastest, least durable
appendfsync everysec
 
# Rewrite threshold
# Rewrite when AOF is 100% larger than after last rewrite
auto-aof-rewrite-percentage 100
# Minimum size before rewrite triggers
auto-aof-rewrite-min-size 64mb
 
# Disable fsync during rewrites (may lose data on crash during rewrite)
no-appendfsync-on-rewrite no
 
# Handle truncated AOF on startup
aof-load-truncated yes
 
# Enable hybrid RDB+AOF format for faster loading (Redis 4.0+)
aof-use-rdb-preamble yes

AOF Rewrite Process

As commands accumulate, the AOF file grows unboundedly. If you increment a counter 1 million times, the AOF contains 1 million INCR commands. AOF rewrite compacts this by generating the minimum set of commands to recreate the current state.

Rewrite Mechanism:

Redis forks a child process (similar to RDB)
Child writes the current dataset as commands to a new AOF file
Parent buffers new commands in memory during rewrite
When child completes, parent appends buffered commands to new AOF
New AOF atomically replaces the old one

The result: 1 million INCRs become a single SET counter 1000000.

Hybrid Persistence (RDB + AOF)

Redis 4.0 introduced hybrid persistence, combining the advantages of both approaches. When enabled via aof-use-rdb-preamble yes, the AOF rewrite produces a file that starts with an RDB snapshot followed by AOF commands that accumulated during the rewrite.

Benefits:

Fast loading: RDB preamble loads quickly (binary, no parsing)
Minimal data loss: AOF tail captures recent changes
Compact file size: RDB portion is highly compressed

This is the recommended configuration for production Redis deployments where durability matters.

Production Persistence Strategy

For most production deployments, enable both RDB and AOF with hybrid persistence:

AOF with everysec fsync for durability
RDB snapshots for efficient backups and disaster recovery
Hybrid persistence for fast restarts

This provides sub-second recovery from crashes and efficient point-in-time backups.

Redis Replication Architecture

Redis replication enables horizontal read scaling and high availability through a leader-follower (master-replica) model. Replicas maintain copies of the master's data and can serve read requests, distributing load across multiple instances.

Replication Fundamentals

Asynchronous by Default:

Redis replication is asynchronous—the master doesn't wait for replicas to acknowledge writes before responding to clients. This prioritizes performance but means replicas may lag behind the master.

Replication Flow:

Replica connects to master and sends PSYNC command
Master initiates full synchronization:
- Forks and generates RDB snapshot
- Sends RDB to replica
- Buffers new commands during transfer
- Sends buffered commands after RDB load
Ongoing partial synchronization:
- Master streams commands to replica
- Replica applies commands to local dataset

redis-replication-setup.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# On replica instances
replicaof 192.168.1.100 6379      # Master IP and port
 
# Authentication (if master requires password)
masterauth your-strong-password
 
# Make replica read-only (recommended)
replica-read-only yes
 
# Serve stale data during sync or disconnection
replica-serve-stale-data yes
 
# Disk-less replication (faster for slow disks)
repl-diskless-sync yes
repl-diskless-sync-delay 5        # Wait 5 seconds for more replicas
 
# Replication backlog for partial resync
repl-backlog-size 64mb
repl-backlog-ttl 3600
 
# Minimum replicas for writes (for durability)
min-replicas-to-write 1
min-replicas-max-lag 10

Partial Resynchronization

When a replica briefly disconnects (network blip, restart), it doesn't need a full sync. Redis maintains a replication backlog—a circular buffer of recent write commands on the master. If the replica's replication offset is within the backlog, only the missed commands are sent.

Replication IDs:

Each Redis instance has a unique replication ID. When a failover promotes a replica to master, the replication ID changes. Replicas check this ID to determine if partial sync is possible or if full sync is required.

Reading from Replicas

Replicas can serve read requests, enabling read scaling. However, this introduces consistency considerations:

Stale reads: Replicas may be milliseconds to seconds behind master
Causal consistency violations: A write followed by read to replica may not see the write

For use cases where this is acceptable (displaying cached data, analytics queries), replica reads dramatically increase read throughput.

Replica Lag in High-Write Scenarios

Monitor replica lag using 'INFO replication' (check 'lag' field for each replica). High lag indicates the replica can't keep up with write volume. Solutions: reduce write rate, use faster network between master and replica, or upgrade replica hardware. Lag greater than your replication backlog size will force a full resync on any disconnect.

Redis Sentinel: High Availability

Redis Sentinel provides automatic failover for Redis replication setups. Without Sentinel, a master failure requires manual intervention to promote a replica. Sentinel monitors Redis instances, detects failures, and orchestrates failover automatically.

Sentinel Architecture

A Sentinel deployment consists of:

Multiple Sentinel processes (minimum 3 for quorum)
One Redis master handling writes
One or more Redis replicas for failover candidates

Sentinel Responsibilities:

Monitoring: Continuously check if master and replicas are working
Notification: Alert administrators or other systems about failures
Automatic Failover: Promote replica to master if master fails
Configuration Provider: Clients query Sentinel for current master address

Converting Mermaid diagram...

Failover Process

Subjective Down (SDOWN): A single Sentinel marks the master as "subjectively down" if it doesn't respond to PING within the configured timeout.

Objective Down (ODOWN): Once a Sentinel declares SDOWN, it queries other Sentinels. If a quorum (configurable, usually majority) agrees the master is down, it's marked "objectively down."

Leader Election: Sentinels elect a leader to perform the failover using a Raft-like consensus algorithm.

Failover Execution:

Selected Sentinel picks the best replica (by priority, replication offset)
Promotes replica to master (REPLICAOF NO ONE)
Reconfigures other replicas to follow new master
Updates its own records of the new master
Publishes new master address for clients

sentinel.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Sentinel configuration
port 26379
 
# Monitor a master named "mymaster" at given address
# Quorum of 2 means 2 Sentinels must agree master is down
sentinel monitor mymaster 192.168.1.100 6379 2
 
# How long to wait before considering master down (ms)
sentinel down-after-milliseconds mymaster 5000
 
# How many replicas can sync from new master simultaneously during failover
sentinel parallel-syncs mymaster 1
 
# Failover timeout (ms) - time to complete failover
sentinel failover-timeout mymaster 60000
 
# Authentication
sentinel auth-pass mymaster your-master-password
 
# Scripts to run on events
sentinel notification-script mymaster /var/lib/redis/notify.sh
sentinel client-reconfig-script mymaster /var/lib/redis/reconfig.sh

Sentinel Deployment Best Practices

Deploy an odd number of Sentinels (3 or 5) across different failure domains
Never run Sentinel on the same machine as Redis
Use at least 3 Sentinels for production to survive one Sentinel failure
Clients must use Sentinel-aware drivers that query Sentinel for master address
Network partitions can cause split-brain—ensure Sentinels have consistent network view

Redis Cluster: Horizontal Scaling

Redis Cluster provides automatic sharding across multiple Redis nodes, enabling datasets that exceed single-machine memory limits. Unlike Sentinel (which provides HA for a single dataset), Cluster partitions data across multiple masters, each responsible for a subset of the keyspace.

Hash Slot Architecture

Redis Cluster divides the keyspace into 16,384 hash slots. Each key is assigned to a slot using:

slot = CRC16(key) mod 16384

Each master in the cluster is responsible for a range of slots. For a 3-master cluster:

Master A: slots 0-5460
Master B: slots 5461-10922
Master C: slots 10923-16383

Key Hashing and Hash Tags:

By default, the entire key determines the slot. Hash tags allow controlling which portion of the key is hashed, ensuring related keys land on the same slot:

user:{1234}:profile  → hash only "{1234}"
user:{1234}:sessions → hash only "{1234}" → same slot!

This enables multi-key operations (MGET, transactions) on related keys.

Converting Mermaid diagram...

Cluster Client Interaction

Cluster clients must be cluster-aware. They maintain a mapping of slots to nodes and route commands accordingly.

MOVED Redirection:

When a client sends a command to the wrong node:

> GET user:5000
-MOVED 5846 192.168.1.102:6379

The client should update its slot mapping and retry at the correct node.

ASK Redirection:

During slot migration, some keys may temporarily be on the target node:

> GET migrating-key
-ASK 5846 192.168.1.102:6379

The client sends ASKING followed by the command to the target node.

Smart Clients:

Production Redis clients (Jedis, lettuce, redis-py, ioredis) handle redirections automatically, cache slot mappings, and refresh mappings on topology changes.

redis-cluster-setup.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Create cluster with 3 masters and 3 replicas (minimum recommended)
redis-cli --cluster create \
    192.168.1.101:6379 \
    192.168.1.102:6379 \
    192.168.1.103:6379 \
    192.168.1.104:6379 \
    192.168.1.105:6379 \
    192.168.1.106:6379 \
    --cluster-replicas 1
 
# Check cluster status
redis-cli -c -h 192.168.1.101 -p 6379 CLUSTER INFO
 
# View slot distribution
redis-cli -c -h 192.168.1.101 -p 6379 CLUSTER SLOTS
 
# Add a new node
redis-cli --cluster add-node 192.168.1.107:6379 192.168.1.101:6379
 
# Reshard slots to new node
redis-cli --cluster reshard 192.168.1.101:6379
 
# Remove a node (must be empty first)
redis-cli --cluster del-node 192.168.1.101:6379 <node-id>

Cluster Failover

Each master in a Redis Cluster can have replicas. When a master fails:

Replicas detect master failure (no heartbeat)
Replicas request votes from other masters
Majority vote promotes one replica to master for those slots
New master announces ownership via cluster bus

Failover Timing:

cluster-node-timeout: How long before a node is considered failing (default: 15s)
Actual failover typically completes within cluster-node-timeout + election time

Redis Cluster Limitations
Limitation	Description	Mitigation
Multi-key operations	Commands spanning multiple slots fail	Use hash tags to co-locate related keys
Transactions	MULTI/EXEC only work within single slot	Design data model around hash tags
Lua scripts	All keys must be on same node	Pass all keys via KEYS, use hash tags
Database selection	Only database 0 is available	Use key prefixes for logical separation
Large key values	Max 512MB per key (as always)	Split into multiple keys if needed

Cluster Sizing Guidelines

• Minimum production: 6 nodes (3 masters + 3 replicas) • Optimal slot distribution: Roughly equal slots per master • Cross-zone replicas: Place replicas in different availability zones • Memory planning: Account for ~10-15% overhead beyond data size • Network: Use dedicated low-latency network for cluster bus traffic

Summary: Redis Mastery

Redis's combination of speed, versatility, and operational flexibility has made it indispensable in modern distributed systems. Let's consolidate the key takeaways:

Key Takeaways

•Redis is more than a cache — It's an in-memory data structure server with native support for strings, lists, sets, sorted sets, hashes, streams, and more.
•Choose the right data structure — Each type offers specific operations with guaranteed complexities. Sorted sets for leaderboards, hashes for objects, streams for event logs.
•Persistence options trade off durability vs performance — RDB for fast restarts and backups, AOF for minimal data loss, hybrid for best of both.
•Replication enables read scaling and HA foundation — Asynchronous replication distributes reads; Sentinel automates failover.
•Redis Cluster provides horizontal scaling — Automatic sharding across 16,384 hash slots enables datasets beyond single-machine memory.
•Understanding limitations guides design — Multi-key operations require hash tags; transactions are slot-scoped; plan data models accordingly.

What's Next:

In the next page, we'll examine Memcached—a simpler, high-performance caching solution that excels in specific scenarios. Understanding both Redis and Memcached's strengths will enable you to make informed technology selections based on your system's requirements.

Page Complete

You now have a comprehensive understanding of Redis's architecture, data structures, persistence mechanisms, replication, and clustering. This knowledge forms the foundation for designing high-performance caching layers in distributed systems.

System Design (HLD)Distributed Cache Systems

Distributed Cache Systems

LevelIntermediate

Duration90 mins

TopicDistributed Cache Systems

1 / 5

Redis: Data Structures, Persistence, and Clustering

The Swiss Army Knife of Distributed Data Stores

What You Will Learn

Redis Architecture Fundamentals

Single-Threaded Event Loop:

Redis Threading Model Evolution
Component	Threading Model	Purpose	Performance Impact
Command Processing	Single-threaded	Atomicity, simplicity, no locks	Predictable latency, ~300K ops/sec per core
Network I/O (Redis 6+)	Multi-threaded (optional)	Handle high connection counts	2-3x throughput improvement
Persistence (RDB)	Background fork	Point-in-time snapshots	Minimal impact on main thread
Persistence (AOF rewrite)	Background fork	Log compaction	Minimal impact on main thread
Lazy object freeing	Background thread	Avoid blocking on large deletes	Instant DEL commands

Memory-First Architecture:

Strings use simple dynamic strings (SDS) with length prefixes
Small lists, sets, and hashes use compact encodings (ziplist, intset, listpack)
Larger collections upgrade to hash tables, skip lists, or quicklists

This automatic encoding optimization means developers get performance benefits without manual tuning in most cases.

Memory Is the Limiting Factor

RESP Protocol (Redis Serialization Protocol):

*3\r
$3\r
SET\r
$5\r
mykey\r
$7\r
myvalue\r

Translates to: SET mykey myvalue

The RESP protocol's simplicity keeps parsing overhead minimal, contributing to Redis's low latency characteristics.

Core Data Structures Deep Dive

Strings: The Foundation

SET key value — O(1)
GET key — O(1)
INCR key / DECR key — O(1) atomic counter
APPEND key value — O(1) amortized
GETRANGE key start end — O(N) where N is substring length

Common Use Cases:

Session tokens: SET session:abc123 "{user_id: 42, expires: ...}"
Page view counters: INCR page:views:/home
Rate limiting: SET ratelimit:user:42 1 EX 60 NX (set if not exists, 60-second expiry)
Distributed locks: SET lock:resource abc123 EX 30 NX

redis-string-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Basic string operations
SET user:1:name "Alice Johnson"
GET user:1:name                    # Returns: "Alice Johnson"
 
# Atomic counter - thread-safe without locks
INCR article:123:views            # Returns: 1
INCR article:123:views            # Returns: 2
INCRBY article:123:views 100      # Returns: 102
 
# Set with expiration (session management)
SET session:xyz789 "user_data..." EX 3600    # Expires in 1 hour
 
# Conditional set (distributed locking)
SET lock:order:5001 "worker-1" NX EX 30      # Only sets if key doesn't exist
 
# Batch operations (reduces network round trips)
MSET user:1:name "Alice" user:1:email "[email protected]"
MGET user:1:name user:1:email

Lists: Ordered Collections

Redis Lists are doubly-linked lists of strings, optimized for insertion and removal at both ends. They're perfect for queues, recent activity feeds, and bounded collections.

LPUSH key value / RPUSH key value — O(1) per element
LPOP key / RPOP key — O(1)
LRANGE key start stop — O(S+N) where S is offset, N is elements returned
LLEN key — O(1)
LINDEX key index — O(N) for middle elements
BLPOP key timeout — Blocking pop (for queue consumers)

Internal Implementation:

redis-list-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Task queue pattern
RPUSH jobs:email '{"to":"[email protected]","subject":"Welcome"}'
RPUSH jobs:email '{"to":"[email protected]","subject":"New signup"}'
 
# Worker consumes from queue (blocking)
BLPOP jobs:email 30               # Blocks up to 30 seconds for item
 
# Recent activity feed (capped at 100 entries)
LPUSH activity:user:42 '{"action":"login","time":"2024-01-15T10:30:00Z"}'
LTRIM activity:user:42 0 99       # Keep only 100 most recent
 
# Get last 10 activities
LRANGE activity:user:42 0 9
 
# Reliable queue with BRPOPLPUSH (atomic move between lists)
BRPOPLPUSH jobs:pending jobs:processing 30   # Move job to processing list

Sets: Unordered Unique Collections

Redis Sets are unordered collections of unique strings. They support fast membership testing and powerful set operations (union, intersection, difference).

SADD key member — O(1)
SISMEMBER key member — O(1)
SMEMBERS key — O(N)
SINTER key1 key2 — O(N*M) where N is smallest set cardinality
SUNION key1 key2 — O(N) sum of all elements
SCARD key — O(1)

Use Cases:

Tag systems: SADD article:123:tags "redis" "caching" "database"
Friend relationships: SADD user:42:friends 101 102 103
Finding mutual friends: SINTER user:42:friends user:101:friends
Unique visitor tracking: SADD visitors:2024-01-15 "ip:1.2.3.4"

Sorted Sets (ZSets): The Workhorse

ZADD key score member — O(log N)
ZRANK key member — O(log N)
ZRANGE key start stop [WITHSCORES] — O(log N + M)
ZRANGEBYSCORE key min max — O(log N + M)
ZINCRBY key increment member — O(log N)
ZCARD key — O(1)

Internal Implementation:

redis-sorted-set-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Leaderboard system
ZADD game:leaderboard 1500 "player:alice"
ZADD game:leaderboard 2200 "player:bob"
ZADD game:leaderboard 1800 "player:charlie"
 
# Get top 10 players
ZREVRANGE game:leaderboard 0 9 WITHSCORES
 
# Get player rank (0-indexed)
ZREVRANK game:leaderboard "player:bob"    # Returns: 0 (top position)
 
# Increment score atomically
ZINCRBY game:leaderboard 500 "player:alice"  # Now 2000
 
# Sliding window rate limiter (timestamp as score)
ZADD ratelimit:user:42 1705300000000 "request:abc"
ZREMRANGEBYSCORE ratelimit:user:42 0 1705296400000   # Remove old entries
ZCARD ratelimit:user:42                               # Count in window
 
# Priority queue
ZADD jobs:priority 1 "urgent-job" 5 "normal-job" 10 "low-priority-job"
ZPOPMIN jobs:priority                      # Get highest priority (lowest score)

Hashes: Structured Objects

Redis Hashes are maps between string fields and string values—ideal for representing objects. They're more memory-efficient than storing JSON strings for objects with many fields.

HSET key field value — O(1)
HGET key field — O(1)
HMSET key field1 value1 field2 value2 — O(N)
HGETALL key — O(N)
HINCRBY key field increment — O(1)
HDEL key field — O(1)

Memory Efficiency:

redis-hash-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# User profile as hash
HSET user:42 name "Alice Johnson" email "[email protected]" signup_date "2024-01-15"
HSET user:42 login_count 0 last_active "2024-01-15T10:30:00Z"
 
# Get specific fields (more efficient than HGETALL)
HMGET user:42 name email
 
# Increment counter field
HINCRBY user:42 login_count 1
 
# Get all fields
HGETALL user:42
 
# Check field existence
HEXISTS user:42 premium_tier    # Returns 0 (doesn't exist)
 
# Shopping cart implementation
HINCRBY cart:session:xyz product:123 2    # Add 2 of product 123
HINCRBY cart:session:xyz product:456 1    # Add 1 of product 456
HDEL cart:session:xyz product:123         # Remove product

When to Use Which Structure

Advanced Data Types

Beyond the core structures, Redis provides specialized types for specific use cases that would otherwise require complex combinations of basic types.

Streams: Log-Style Data Structure

Key Operations:

XADD stream-key * field value — Append entry, auto-generate ID
XREAD STREAMS stream-key ID — Read entries after ID
XREADGROUP GROUP group consumer STREAMS stream-key > — Consumer group read
XACK stream-key group id — Acknowledge message processing
XPENDING stream-key group — List pending (unacknowledged) messages

redis-streams-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Event stream for order processing
XADD orders:events * event "order_created" order_id "5001" customer_id "42"
XADD orders:events * event "payment_received" order_id "5001" amount "99.99"
XADD orders:events * event "order_shipped" order_id "5001" tracking "TRK123"
 
# Create consumer group starting from beginning
XGROUP CREATE orders:events fulfillment-workers $ MKSTREAM
 
# Worker reads from group (blocking)
XREADGROUP GROUP fulfillment-workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders:events >
 
# Acknowledge processed message
XACK orders:events fulfillment-workers 1705300000000-0
 
# View pending messages (not yet acknowledged)
XPENDING orders:events fulfillment-workers

HyperLogLog: Probabilistic Cardinality Estimation

PFADD key element — Add element(s)
PFCOUNT key — Estimate unique count
PFMERGE destkey sourcekey1 sourcekey2 — Merge HLLs

Use Cases:

Unique visitor counting per page/day
Unique search queries
Distinct IP addresses

redis-hyperloglog-example.txt
1
2
3
4
5
6
7
8
9
10
# Track unique visitors by day
PFADD visitors:2024-01-15 "user:1" "user:2" "user:3" "user:1"  # user:1 counted once
PFCOUNT visitors:2024-01-15                                      # Returns: 3
 
# Merge for weekly count
PFMERGE visitors:week:3 visitors:2024-01-15 visitors:2024-01-16 visitors:2024-01-17
PFCOUNT visitors:week:3
 
# Compare: exact count would require O(N) memory
# HyperLogLog uses fixed 12KB for any N (billions of elements)

Bitmaps: Compact Boolean Arrays

Bitmaps treat strings as bit arrays, enabling extremely memory-efficient storage of boolean values. One million boolean values require only 125KB.

SETBIT key offset value — Set bit at position
GETBIT key offset — Get bit at position
BITCOUNT key [start end] — Count set bits
BITOP AND destkey key1 key2 — Bitwise operations

Use Cases:

User login tracking: Bit per day, bit position = user ID
Feature flags per user
Real-time analytics

Geospatial: Location-Based Queries

Redis Geo commands store longitude/latitude pairs and enable proximity queries. Internally, this uses Sorted Sets with geohash encoding.

GEOADD key longitude latitude member
GEODIST key member1 member2 [km|m|mi]
GEORADIUS key longitude latitude radius unit
GEOSEARCH key FROMMEMBER member BYRADIUS radius unit

redis-geo-example.txt
1
2
3
4
5
6
7
8
9
10
11
# Store restaurant locations
GEOADD restaurants -122.419 37.775 "restaurant:pizza-palace"
GEOADD restaurants -122.421 37.773 "restaurant:burger-barn"
GEOADD restaurants -122.417 37.777 "restaurant:taco-town"
 
# Find restaurants within 1km of coordinates
GEORADIUS restaurants -122.420 37.774 1 km WITHDIST
# Returns: pizza-palace (0.15km), burger-barn (0.14km), taco-town (0.38km)
 
# Distance between two places
GEODIST restaurants "restaurant:pizza-palace" "restaurant:taco-town" km

Persistence: RDB Snapshots

RDB (Redis Database) Snapshots

How RDB Works:

Redis forks the main process using copy-on-write (COW)
The child process writes the dataset to a temporary RDB file
When complete, the temp file atomically replaces the old RDB file
The parent continues serving requests during the entire process

The Fork Operation:

RDB Configuration and Behavior
Configuration	Default	Description
save 900 1	Enabled	Save after 900 seconds if at least 1 key changed
save 300 10	Enabled	Save after 300 seconds if at least 10 keys changed
save 60 10000	Enabled	Save after 60 seconds if at least 10000 keys changed
stop-writes-on-bgsave-error	yes	Stop accepting writes if background save fails
rdbcompression	yes	Use LZF compression for strings in RDB
rdbchecksum	yes	Add CRC64 checksum for corruption detection

redis-rdb-configuration.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# RDB snapshot configuration
# Format: save <seconds> <changes>
save 900 1        # Save after 15 minutes if at least 1 change
save 300 10       # Save after 5 minutes if at least 10 changes
save 60 10000     # Save after 1 minute if at least 10000 changes
 
# Disable RDB entirely (not recommended for production)
# save ""
 
# RDB file location
dir /var/lib/redis
dbfilename dump.rdb
 
# Enable compression (recommended)
rdbcompression yes
 
# Enable checksum verification
rdbchecksum yes
 
# Manual snapshot command
# BGSAVE     - Async background save
# SAVE       - Sync save (blocks server - avoid in production)
# LASTSAVE   - Timestamp of last successful save

RDB Advantages

•Compact single file — Easy to backup, transfer, and version
•Fast restarts — Loading RDB is faster than replaying AOF
•Minimal performance impact — Fork and background write
•Efficient for backups — Point-in-time snapshots ideal for DR
•Disaster recovery — Transfer to remote datacenter easily

RDB Disadvantages

•Potential data loss — Lose data between snapshots on crash
•Fork overhead — Large datasets cause significant fork time
•Write amplification — COW copies entire pages on modification
•Memory spike — During saves, memory usage can double
•Not real-time — Minutes of data loss possible

Fork Latency with Large Datasets

Persistence: AOF (Append-Only File)

How AOF Works

Every write command is appended to the AOF file
Periodically, Redis rewrites the AOF to remove redundant commands
On restart, Redis replays the AOF to reconstruct the dataset

Fsync Policies:

The critical configuration is how often Redis forces the OS to flush the AOF buffer to disk. This determines your durability guarantee:

always — Fsync after every command. Maximum durability, slowest performance.
everysec — Fsync once per second. Balanced approach, recommended.
no — Let the OS decide when to flush. Fastest, but up to 30+ seconds of data loss possible.

AOF Fsync Policies Comparison
Policy	Data Loss Risk	Performance	Recommended For
always	None (one command)	Slowest (10x slower)	Financial transactions, audit logs
everysec	~1 second	Good (slight overhead)	Most production workloads (default)
no	Up to 30+ seconds	Fastest	Ephemeral cache, acceptable loss

redis-aof-configuration.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Enable AOF
appendonly yes
 
# AOF file name
appendfilename "appendonly.aof"
 
# Fsync policy
# always: every command - maximum durability, slowest
# everysec: once per second - recommended balance
# no: OS decides - fastest, least durable
appendfsync everysec
 
# Rewrite threshold
# Rewrite when AOF is 100% larger than after last rewrite
auto-aof-rewrite-percentage 100
# Minimum size before rewrite triggers
auto-aof-rewrite-min-size 64mb
 
# Disable fsync during rewrites (may lose data on crash during rewrite)
no-appendfsync-on-rewrite no
 
# Handle truncated AOF on startup
aof-load-truncated yes
 
# Enable hybrid RDB+AOF format for faster loading (Redis 4.0+)
aof-use-rdb-preamble yes

AOF Rewrite Process

Rewrite Mechanism:

Redis forks a child process (similar to RDB)
Child writes the current dataset as commands to a new AOF file
Parent buffers new commands in memory during rewrite
When child completes, parent appends buffered commands to new AOF
New AOF atomically replaces the old one

The result: 1 million INCRs become a single SET counter 1000000.

Hybrid Persistence (RDB + AOF)

Benefits:

Fast loading: RDB preamble loads quickly (binary, no parsing)
Minimal data loss: AOF tail captures recent changes
Compact file size: RDB portion is highly compressed

This is the recommended configuration for production Redis deployments where durability matters.

Production Persistence Strategy

For most production deployments, enable both RDB and AOF with hybrid persistence:

AOF with everysec fsync for durability
RDB snapshots for efficient backups and disaster recovery
Hybrid persistence for fast restarts

This provides sub-second recovery from crashes and efficient point-in-time backups.

Redis Replication Architecture

Replication Fundamentals

Asynchronous by Default:

Redis replication is asynchronous—the master doesn't wait for replicas to acknowledge writes before responding to clients. This prioritizes performance but means replicas may lag behind the master.

Replication Flow:

Replica connects to master and sends PSYNC command
Master initiates full synchronization:
- Forks and generates RDB snapshot
- Sends RDB to replica
- Buffers new commands during transfer
- Sends buffered commands after RDB load
Ongoing partial synchronization:
- Master streams commands to replica
- Replica applies commands to local dataset

redis-replication-setup.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# On replica instances
replicaof 192.168.1.100 6379      # Master IP and port
 
# Authentication (if master requires password)
masterauth your-strong-password
 
# Make replica read-only (recommended)
replica-read-only yes
 
# Serve stale data during sync or disconnection
replica-serve-stale-data yes
 
# Disk-less replication (faster for slow disks)
repl-diskless-sync yes
repl-diskless-sync-delay 5        # Wait 5 seconds for more replicas
 
# Replication backlog for partial resync
repl-backlog-size 64mb
repl-backlog-ttl 3600
 
# Minimum replicas for writes (for durability)
min-replicas-to-write 1
min-replicas-max-lag 10

Partial Resynchronization

Replication IDs:

Reading from Replicas

Replicas can serve read requests, enabling read scaling. However, this introduces consistency considerations:

Stale reads: Replicas may be milliseconds to seconds behind master
Causal consistency violations: A write followed by read to replica may not see the write

For use cases where this is acceptable (displaying cached data, analytics queries), replica reads dramatically increase read throughput.

Replica Lag in High-Write Scenarios

Redis Sentinel: High Availability

Sentinel Architecture

A Sentinel deployment consists of:

Multiple Sentinel processes (minimum 3 for quorum)
One Redis master handling writes
One or more Redis replicas for failover candidates

Sentinel Responsibilities:

Monitoring: Continuously check if master and replicas are working
Notification: Alert administrators or other systems about failures
Automatic Failover: Promote replica to master if master fails
Configuration Provider: Clients query Sentinel for current master address

Converting Mermaid diagram...

Failover Process

Subjective Down (SDOWN): A single Sentinel marks the master as "subjectively down" if it doesn't respond to PING within the configured timeout.

Objective Down (ODOWN): Once a Sentinel declares SDOWN, it queries other Sentinels. If a quorum (configurable, usually majority) agrees the master is down, it's marked "objectively down."

Leader Election: Sentinels elect a leader to perform the failover using a Raft-like consensus algorithm.

Failover Execution:

Selected Sentinel picks the best replica (by priority, replication offset)
Promotes replica to master (REPLICAOF NO ONE)
Reconfigures other replicas to follow new master
Updates its own records of the new master
Publishes new master address for clients

sentinel.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Sentinel configuration
port 26379
 
# Monitor a master named "mymaster" at given address
# Quorum of 2 means 2 Sentinels must agree master is down
sentinel monitor mymaster 192.168.1.100 6379 2
 
# How long to wait before considering master down (ms)
sentinel down-after-milliseconds mymaster 5000
 
# How many replicas can sync from new master simultaneously during failover
sentinel parallel-syncs mymaster 1
 
# Failover timeout (ms) - time to complete failover
sentinel failover-timeout mymaster 60000
 
# Authentication
sentinel auth-pass mymaster your-master-password
 
# Scripts to run on events
sentinel notification-script mymaster /var/lib/redis/notify.sh
sentinel client-reconfig-script mymaster /var/lib/redis/reconfig.sh

Sentinel Deployment Best Practices

Deploy an odd number of Sentinels (3 or 5) across different failure domains
Never run Sentinel on the same machine as Redis
Use at least 3 Sentinels for production to survive one Sentinel failure
Clients must use Sentinel-aware drivers that query Sentinel for master address
Network partitions can cause split-brain—ensure Sentinels have consistent network view

Redis Cluster: Horizontal Scaling

Hash Slot Architecture

Redis Cluster divides the keyspace into 16,384 hash slots. Each key is assigned to a slot using:

slot = CRC16(key) mod 16384

Each master in the cluster is responsible for a range of slots. For a 3-master cluster:

Master A: slots 0-5460
Master B: slots 5461-10922
Master C: slots 10923-16383

Key Hashing and Hash Tags:

By default, the entire key determines the slot. Hash tags allow controlling which portion of the key is hashed, ensuring related keys land on the same slot:

user:{1234}:profile  → hash only "{1234}"
user:{1234}:sessions → hash only "{1234}" → same slot!

This enables multi-key operations (MGET, transactions) on related keys.

Converting Mermaid diagram...

Cluster Client Interaction

Cluster clients must be cluster-aware. They maintain a mapping of slots to nodes and route commands accordingly.

MOVED Redirection:

When a client sends a command to the wrong node:

> GET user:5000
-MOVED 5846 192.168.1.102:6379

The client should update its slot mapping and retry at the correct node.

ASK Redirection:

During slot migration, some keys may temporarily be on the target node:

> GET migrating-key
-ASK 5846 192.168.1.102:6379

The client sends ASKING followed by the command to the target node.

Smart Clients:

Production Redis clients (Jedis, lettuce, redis-py, ioredis) handle redirections automatically, cache slot mappings, and refresh mappings on topology changes.

redis-cluster-setup.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Create cluster with 3 masters and 3 replicas (minimum recommended)
redis-cli --cluster create \
    192.168.1.101:6379 \
    192.168.1.102:6379 \
    192.168.1.103:6379 \
    192.168.1.104:6379 \
    192.168.1.105:6379 \
    192.168.1.106:6379 \
    --cluster-replicas 1
 
# Check cluster status
redis-cli -c -h 192.168.1.101 -p 6379 CLUSTER INFO
 
# View slot distribution
redis-cli -c -h 192.168.1.101 -p 6379 CLUSTER SLOTS
 
# Add a new node
redis-cli --cluster add-node 192.168.1.107:6379 192.168.1.101:6379
 
# Reshard slots to new node
redis-cli --cluster reshard 192.168.1.101:6379
 
# Remove a node (must be empty first)
redis-cli --cluster del-node 192.168.1.101:6379 <node-id>

Cluster Failover

Each master in a Redis Cluster can have replicas. When a master fails:

Replicas detect master failure (no heartbeat)
Replicas request votes from other masters
Majority vote promotes one replica to master for those slots
New master announces ownership via cluster bus

Failover Timing:

cluster-node-timeout: How long before a node is considered failing (default: 15s)
Actual failover typically completes within cluster-node-timeout + election time

Redis Cluster Limitations
Limitation	Description	Mitigation
Multi-key operations	Commands spanning multiple slots fail	Use hash tags to co-locate related keys
Transactions	MULTI/EXEC only work within single slot	Design data model around hash tags
Lua scripts	All keys must be on same node	Pass all keys via KEYS, use hash tags
Database selection	Only database 0 is available	Use key prefixes for logical separation
Large key values	Max 512MB per key (as always)	Split into multiple keys if needed

Cluster Sizing Guidelines

Summary: Redis Mastery

Redis's combination of speed, versatility, and operational flexibility has made it indispensable in modern distributed systems. Let's consolidate the key takeaways:

Key Takeaways

•Redis is more than a cache — It's an in-memory data structure server with native support for strings, lists, sets, sorted sets, hashes, streams, and more.
•Choose the right data structure — Each type offers specific operations with guaranteed complexities. Sorted sets for leaderboards, hashes for objects, streams for event logs.
•Persistence options trade off durability vs performance — RDB for fast restarts and backups, AOF for minimal data loss, hybrid for best of both.
•Replication enables read scaling and HA foundation — Asynchronous replication distributes reads; Sentinel automates failover.
•Redis Cluster provides horizontal scaling — Automatic sharding across 16,384 hash slots enables datasets beyond single-machine memory.
•Understanding limitations guides design — Multi-key operations require hash tags; transactions are slot-scoped; plan data models accordingly.

What's Next:

Page Complete