Unlock Redis Mastery: 40+ Diagrams & 30k Words of Interview Essentials

Redis Overview

Redis is an in‑memory database that offers extremely fast read/write operations, making it ideal for caching, message queues, and distributed locks.

It supports multiple data types—String, Hash, List, Set, Zset, Bitmap, HyperLogLog, GEO, and Stream—each with atomic operations because commands are processed by a single thread.

Redis vs. Memcached

Both are memory‑based caches.

Redis provides richer data structures, persistence, native clustering, Lua scripting, transactions, and pub/sub, which Memcached lacks.

Why Use Redis as MySQL Cache?

Redis delivers high performance and concurrency, handling up to 100k QPS, far exceeding MySQL's capacity, allowing hot data to be served directly from memory.

Redis Data Structures

Core Types and Use Cases

String : object caching, counters, distributed locks, session storage.

List : message queues (with caveats).

Hash : object caching, shopping carts.

Set : set operations like likes, mutual follows, lotteries.

Zset : ranking, sorted lists.

Additional types introduced in later versions:

Bitmap : binary state tracking (e.g., sign‑in status).

HyperLogLog : cardinality estimation for massive datasets.

GEO : geographic location storage.

Stream : advanced message queue with unique IDs and consumer groups.

Internal Implementations

String uses SDS (simple dynamic strings) which store length for O(1) size queries and support binary data safely.

List was originally a doubly linked list or ziplist; since Redis 3.2 it uses quicklist for all cases.

Hash uses ziplist for small hashes or a hash table otherwise; ziplist was replaced by listpack in Redis 7.0.

Set uses a hash table or an integer set when all members are integers and small.

Zset uses a ziplist for small sorted sets or a skiplist for larger ones; listpack replaces ziplist in Redis 7.0.

Thread Model

Is Redis Single‑Threaded?

The main client request‑processing pipeline (accept, parse, execute, reply) runs on a single thread, which is why Redis is described as single‑threaded.

However, Redis spawns background I/O (BIO) threads for tasks such as closing files, AOF fsync, and lazy memory freeing. Since Redis 4.0, a lazy‑free thread handles asynchronous deletions.

Event Loop (Pre‑6.0)

Redis creates an epoll object, binds a listening socket, registers connection events, and enters an event loop that processes send queues, accepts new connections, reads client data, parses commands, executes them, and queues responses.

Multi‑Threaded I/O (Redis 6.0+)

Redis 6.0 introduces optional I/O threads for network reads/writes, improving throughput on fast networks while keeping command execution single‑threaded.

Persistence

How Does Redis Avoid Data Loss?

Redis offers three persistence mechanisms:

AOF (Append‑Only File) : every write command is appended to a log file.

RDB Snapshot : periodic binary dumps of the entire dataset.

Hybrid Persistence (Redis 4.0+): combines RDB for fast loading with AOF for minimal data loss.

AOF Details

After a write command, Redis buffers the command, writes it to the OS page cache, and later flushes to disk based on the appendfsync policy (always, everysec, or no).

AOF rewriting creates a new compacted file by scanning the current dataset and writing a minimal set of commands; the rewrite runs in a child process while the parent continues serving clients.

RDB Details

RDB snapshots are generated either synchronously with SAVE (blocking the main thread) or asynchronously with BGSAVE (forking a child process). The child uses copy‑on‑write, allowing the parent to keep serving requests.

Hybrid Persistence

During AOF rewrite, the child writes the dataset in RDB format as the first part of the new AOF file, followed by incremental AOF commands, achieving fast restarts with low data loss.

Redis Cluster & High Availability

High‑Availability Mechanisms

Master‑Slave Replication : asynchronous data propagation from one master to multiple slaves.

Sentinel : monitors masters and slaves, performs automatic failover.

Cluster (Sharding) : distributes slots (16384 total) across nodes, enabling horizontal scaling.

Cluster Slot Mapping

Keys are hashed with CRC16, then modulo 16384 to obtain a slot. Slots are evenly or manually assigned to nodes.

Split‑Brain Scenario

If network partitions cause two masters, the old master is demoted after the new master is elected; to avoid data loss, configure min‑slaves‑to‑write and min‑slaves‑max‑lag so a master without enough healthy slaves refuses writes.

Expiration & Memory Eviction

Expiration Deletion Strategies

Redis combines lazy deletion (checking expiration on access) with periodic random sampling (20 keys per cycle, deleting expired ones, repeating while >25% are expired) to balance CPU usage and memory reclamation.

Persistence and Expiration

Expired keys are omitted from new RDB files and are not loaded into a master on restart. In AOF, expired keys are kept until a rewrite removes them, after which a DEL command is appended when the key finally expires.

Memory Eviction Policies

Eight policies exist:

noeviction : reject writes when maxmemory is reached.

volatile‑random, volatile‑ttl, volatile‑lru, volatile‑lfu : evict only keys with an expiration.

allkeys‑random, allkeys‑lru, allkeys‑lfu : evict any key.

LRU is approximated by sampling a few keys and discarding the least recently used; LFU tracks access frequency using a 24‑bit field split into timestamp and logarithmic counter.

Cache Design Patterns

Avoiding Cache Problems

Cache Snowball : randomize TTLs or refresh caches proactively.

Cache Penetration : filter illegal requests, cache null values, or use Bloom filters.

Cache Breakdown : use mutex locks (e.g., SETNX) or keep hot keys non‑expiring and refreshed in background.

Dynamic Hot‑Key Caching

Maintain a sorted set of hot items (e.g., top‑1000 products) updated by access timestamps, periodically evict low‑rank items, and fetch missing items from the database.

Cache Update Strategies

Common patterns include:

Cache‑Aside : application reads/writes DB then updates or invalidates cache.

Read‑Through / Write‑Through : cache sits between app and DB, automatically loading and persisting data.

Write‑Back : writes go to cache first and are flushed to DB asynchronously (rarely used with Redis).

Advanced Redis Topics

Delayed Queues

Implement with a sorted set where the score is the future execution timestamp; workers poll ZRANGEBYSCORE for ready items.

Large Keys

Identify with redis-cli --bigkeys or SCAN + MEMORY USAGE. Delete large keys incrementally (e.g., HSCAN, SPOP, ZREMRANGEBYRANK) or asynchronously with UNLINK.

Pipelines

Batch multiple commands client‑side to reduce round‑trip latency; avoid overly large pipelines that could cause network back‑pressure.

Transactions

Redis transactions are atomic only in queuing; they lack rollback. DISCARD clears the queued commands, but errors during EXEC do not revert already executed commands.

Distributed Locks

Use SET key value NX PX ttl to acquire a lock with a unique value and expiration. Release safely with a Lua script that deletes the key only if the stored value matches. For higher reliability across nodes, implement the Redlock algorithm: acquire the lock on a majority of independent Redis instances, verify timing constraints, and release with the same Lua script on all nodes.

Redlock Details

Client records start time, attempts SET with NX and PX on N nodes, measures elapsed time, and considers the lock acquired if it succeeded on at least N/2+1 nodes within the lock’s TTL. On failure, it releases any partial locks.