Blog 14 — Redis: Architecture Internals

C

Qubits of DPK

March 21, 2026

Core Case Studies
Source: https://redis.io/blog/
Core Concept: Single-threaded event loop, Redis Cluster + consistent hashing, Eviction policies (LRU, LFU), Redis Sentinel for HA
Why SDE-2 Critical: Every backend interview touches caching — surface-level Redis knowledge is not enough at SDE-2 level
Status: Draft notes ready

Quick Revision

  • Problem: Keep ultra-hot data in memory without turning the cache into a single point of failure.
  • Core pattern: Single-threaded command execution, persistence options, and cluster/sentinel modes.
  • Interview one-liner: Redis is fast because it keeps the model simple and pushes complexity to topology choices.

️ Architecture Overview

javascript
QUBITS OF DPK
1App Server → Redis Client → Redis Server
2
3Redis Server internals:
4  ├── Single-threaded event loop (command processing)
5  ├── In-memory data store (all data in RAM)
6  ├── Optional persistence (RDB snapshots / AOF log)
7  └── Replication (master → replicas)
8
9At scale:
10  ├── Redis Sentinel (HA — automatic failover)
11  └── Redis Cluster (sharding — horizontal scale)

Core Concepts

Why Single-Threaded is Actually Fast

javascript
QUBITS OF DPK
1Counter-intuitive fact: Redis processes ONE command at a time
2
3Why is it still fast (1M+ ops/sec)?
4  ✓ All data in RAM → no disk I/O
5  ✓ No thread context switching overhead
6  ✓ No mutex locks needed → no deadlocks
7  ✓ Event loop handles thousands of connections via epoll
8  ✓ Commands complete in microseconds
9
10Bottleneck is network I/O, not CPU → single thread is enough
11
12Redis 6.0+ added I/O threads for network (still single-threaded for commands)

Redis Persistence Options

javascript
QUBITS OF DPK
1RDB (Redis Database Snapshot):
2  Fork process → dump all data to disk every N minutes
3  Pros: Compact, fast restart
4  Cons: Lose up to N minutes of data on crash
5
6AOF (Append-Only File):
7  Log every write command to disk
8  Pros: Near-zero data loss (configurable: every write / every second)
9  Cons: Larger files, slower restart
10
11Production recommendation:
12  Use both: RDB for backups + AOF for durability

Eviction Policies

javascript
QUBITS OF DPK
1When Redis memory is full, what to evict?
2
3Policies:
4  noeviction    → return error (never evict) — for critical data
5  allkeys-lru   → evict least recently used key — most common
6  allkeys-lfu   → evict least frequently used key — better for popularity
7  volatile-lru  → evict LRU only among keys with TTL set
8  volatile-ttl  → evict key with shortest TTL first
9
10Interview tip:
11  LRU = recency (recently used = valuable)
12  LFU = frequency (often used = valuable, even if not recently)
13  LFU is better for caching trending content (viral tweet = high frequency)

Redis Cluster (Horizontal Sharding)

javascript
QUBITS OF DPK
1Redis Cluster uses 16384 hash slots:
2  hash_slot = CRC16(key) % 16384
3
43 master nodes:
5  Node A: slots 0 – 5460
6  Node B: slots 5461 – 10922
7  Node C: slots 10923 – 16383
8
9SET user:1001 "Alice"
10  CRC16("user:1001") % 16384 = 7230
11  → Belongs to Node B
12  → Request routes to Node B
13
14Add Node D:
15  Move some slots from A, B, C to D
16  No downtime — slot migration is live

Redis Sentinel (High Availability)

javascript
QUBITS OF DPK
1Sentinel monitors master + replicas:
2  If master fails → Sentinel elects a replica as new master
3  Clients notified of new master address
4  Old master rejoins as replica when recovered
5
6Minimum 3 Sentinel instances (quorum = 2):
7  Prevents split-brain (majority must agree master is down)

Performance

5 Interview Questions This Blog Unlocks

Q1. How does Redis handle 1 million operations per second with a single thread?

Answer: All data in RAM (no disk I/O). Single thread eliminates mutex overhead and context switching. Event loop multiplexes thousands of connections via epoll. Each command executes in microseconds. Bottleneck is network, not CPU — single thread is sufficient.

Q2. What is the difference between LRU and LFU eviction?

Answer: LRU (Least Recently Used) evicts the key not accessed for the longest time. Good for temporal access patterns. LFU (Least Frequently Used) evicts the key accessed fewest times. Better for popularity-based caching — a viral tweet used 1M times/day won't be evicted even if not accessed in the last minute.

Q3. What is consistent hashing and how does Redis Cluster use it?

Answer: Redis Cluster uses 16384 fixed hash slots. Each key maps to a slot via CRC16(key) % 16384. Nodes own ranges of slots. Adding/removing nodes means migrating only some slots, not rehashing everything. Unlike naive modulo hashing, only K/N keys remapped when N changes.

Q4. What is the difference between Redis Sentinel and Redis Cluster?

Answer: Sentinel = high availability for single-shard Redis. Monitors master, promotes replica on failure. Cluster = horizontal scaling + HA. Data sharded across multiple masters. Each master has replicas. Built-in failover. Use Sentinel when dataset fits in one node. Use Cluster when you need to shard.

Q5. How do you prevent cache stampede in Redis?

Answer: Three approaches: (1) Mutex lock: first request acquires lock, fetches from DB, sets cache, releases lock. Others wait. (2) Probabilistic early expiration: before TTL expires, randomly refresh with small probability. (3) Cache warming: pre-load popular keys before they expire. Combination of all three is production-grade.

Key Engineering Lessons