Redis

Single-threaded event loop for command execution

Redis's core command execution is single-threaded, and it's a deliberate design choice, not a limitation the project hasn't gotten around to fixing. A single reactor thread runs an event loop (built on epoll/kqueue, similar in spirit to how Node's libuv event loop multiplexes I/O — see backend/node/02-event_loop_libuv/) that:

1. Waits for readiness on client sockets.
2. Reads a command off a ready socket.
3. Executes it synchronously, to completion, against the in-memory data structures.
4. Writes the reply back.
5. Moves to the next ready socket.

Because only one command ever executes at a time, every command is inherently atomic with respect to every other command — there's no possibility of two INCRs interleaving, no locks needed around the hash table, no torn reads on a HGETALL. This is the single biggest reason Redis's data-structure operations (transactions included) are safe by default without any explicit locking in application code.

The trade-off: a single slow command (an O(n) command like KEYS * or a huge SORT on a million-element list) blocks every other client for its entire duration, since there's no preemption within the event loop. This is why Redis documentation consistently warns against KEYS in production (use SCAN, which is cursor-based and does bounded work per call) and why commands with a data-size-dependent cost are flagged in the docs.

Since Redis 6, background threads exist for auxiliary work — I/O reading, and for UNLINK/lazy-freeing large deleted keys — but command execution itself remains single-threaded. This is a narrower use of extra threads than Memcached's fully multi-threaded model (see 02-memcached/cache_memcached_theory.md and the head-to-head in 03-redis_vs_memcached/).

Why it's fast: everything lives in RAM

Every key and value Redis serves a read for is already resident in process memory — there is no disk seek, no page cache miss, no filesystem call on the read path at all. Combined with data structures chosen specifically for their algorithmic complexity (hash table for the keyspace itself: O(1) average; skip list backing sorted sets: O(log n) insert/range; intrusive linked lists for the List type: O(1) push/pop at either end), the result is that almost every Redis operation completes in microseconds, bounded by CPU cache and memory bus speed rather than I/O latency.

This is also Redis's fundamental limitation: the dataset must fit in RAM (modulo Redis's own on-disk overflow features, which are exceptions, not the default mode), which is why capacity planning for Redis is a memory-sizing exercise, and why TTL-based eviction (see 07-ttl/) matters so much in practice — an unbounded cache is an unbounded RAM bill.

Persistence: RDB snapshots vs. AOF

An in-memory store needs an explicit strategy for surviving a restart or crash, since RAM is volatile. Redis offers two real, independently-configurable mechanisms:

RDB (Redis Database file) — point-in-time binary snapshots of the entire dataset.

redis-cli BGSAVE   # forks a child process; child writes a compact binary snapshot to disk
                    # the parent process keeps serving requests uninterrupted (copy-on-write pages)

• Fast to load on restart (raw binary deserialization).
• Compact on disk.
• Data loss window: anything written between the last successful snapshot and a crash is gone. If you snapshot every 5 minutes and crash at minute 4:59, you lose ~5 minutes of writes.

AOF (Append-Only File) — logs every write command as it happens, in order.

# conceptually, the AOF file accumulates entries like:
SET user:1:name "Ana"
INCR pageviews
HSET user:1 age 30

• Replaying the AOF from an empty database reconstructs exact state, command by command.
• Configurable fsync policy trades durability for throughput: appendfsync always (fsync every write — safest, slowest), everysec (fsync once per second — the common default compromise, up to ~1 second of loss), no (let the OS decide when to flush — fastest, largest loss window).
• The file grows unboundedly with write volume; Redis periodically runs AOF rewrite (BGREWRITEAOF) — forking a child process that writes a fresh, compact AOF reflecting only current state (functionally similar to how an RDB snapshot is produced), then atomically swaps it in.
• Slower to replay on restart than loading an RDB (must re-execute every logged command), and the file is larger on disk.

The real trade-off, stated precisely: RDB minimizes restart time and disk footprint at the cost of a coarser data-loss window; AOF minimizes the data-loss window (down to sub-second with everysec) at the cost of restart time and disk space. Production Redis commonly runs both together — RDB for fast full backups/restores, AOF for tight durability — which is why redis.conf exposes both save (RDB) and appendonly yes (AOF) as independent settings rather than an either/or choice.

Eviction under memory pressure

When maxmemory is set and the limit is reached, Redis needs a policy for which keys to evict to make room for new writes — configured via maxmemory-policy (noeviction, allkeys-lru, volatile-lru, allkeys-lfu, volatile-ttl, etc.). This connects directly to TTL semantics (07-ttl/) and to eviction strategy comparisons in 04-caching_strategies/.