Redis Internals

Additional TopicsSeniorredis

The Question

How does Redis work internally?

What a Strong Answer Covers

• Single-threaded + epoll. RDB vs AOF tradeoffs. fork+COW for RDB snapshots.

Senior-Level Answer

Redis is an in-memory data structure store. Understanding its internals explains both its performance characteristics and its limitations.

**Single-threaded event loop**: Redis processes commands on a single thread using an I/O event loop (based on epoll/kqueue). This eliminates lock contention and context-switch overhead, giving Redis predictably low latency—typically sub-millisecond. The single-threaded model means CPU is rarely the bottleneck; network I/O and memory bandwidth are. Redis 6.0 added threaded I/O for reading/writing network data, but command execution itself remains single-threaded.

**Data structures**: Redis stores all values as one of its specialized data structures, each with a compact internal encoding that switches based on size. Lists are stored as listpacks (formerly ziplist) for small sizes and doubly-linked lists for large. Sets are intsets (sorted arrays of integers) for small integer sets, hashtables otherwise. Sorted sets use a skiplist + hashtable dual structure: the skiplist enables O(log N) range queries, the hashtable enables O(1) score lookups by member. Hashes use listpack when small, hashtable when large. These automatic encoding switches save significant memory.

**Memory model**: Redis uses jemalloc and stores all data in RAM. Key expiry is handled lazily (checked on access) and actively (periodic sampling of random keys to evict expired ones). When `maxmemory` is set, eviction policies (LRU, LFU, random, volatile-only variants) determine what gets evicted under memory pressure.

**Persistence**: Two mechanisms. **RDB snapshots** fork the process and write a point-in-time binary dump—fast to restore, but can lose minutes of data. **AOF (Append-Only File)** logs every write command; `fsync` policy (`always`, `everysec`, `no`) controls durability vs. performance trade-off. `everysec` is the common default: at most 1 second of data loss. AOF rewrite compacts the log by re-emitting the current state. Many deployments use both: AOF for durability, RDB for fast restarts.

**Replication** is asynchronous: replicas stream the replication backlog from the primary. Redis Cluster shards data across nodes using 16384 hash slots with gossip-based cluster management. Sentinel provides HA for non-cluster deployments via leader election and automatic failover.

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying Redis is 'completely single-threaded' — Redis 6+ uses threads for network I/O, just not for command execution
• Not knowing that data structures switch internal encodings based on size — this is a key memory optimization
• Treating RDB and AOF as mutually exclusive — most production setups use both
• Confusing Redis Sentinel (HA for single-shard) with Redis Cluster (sharding + HA)

Follow-Up Questions

• How does Redis handle key expiry, and what are the two strategies used? — Lazy expiry: check TTL on access and delete if expired. Active expiry: periodic random sampling of keys with TTLs, deleting expired ones. Pure lazy expiry would leave many stale keys consuming memory.
• Why does a Redis ZADD use both a skiplist and a hashtable? — The hashtable gives O(1) score lookup by member name. The skiplist gives O(log N) rank and range queries. The dual structure trades memory for query flexibility.
• What is the impact of Redis forking for RDB snapshots on a memory-pressured system? — fork() is copy-on-write, but the OS page table itself can be large. On a write-heavy workload, CoW causes memory usage to double during the snapshot. This can trigger OOM if memory is not headroomed.
• What does 'Redis is single-threaded' actually mean after version 6? — Command processing and data access are still single-threaded. Network read/write (parsing requests, writing responses) can use a thread pool. Blocking commands still block the main thread.

Related Questions

• CAP theorem
• SQL vs NoSQL
• Big O basics
• N+1 problem
• AI tools in workflow