Why Redis Is Fast Despite Being Single-Threaded

Problem Why is Redis extremely fast, and how does it handle large scale despite being single-threaded?

Be ready to discuss

• In-memory first: no disk I/O on the read/write hot path, so operations are memory-speed; persistence (RDB snapshots, AOF) is deliberately off the critical path.
• Single-threaded command loop: one thread executing commands eliminates lock contention and context switching, makes every command atomic by construction, and keeps the implementation simple — the CPU was rarely the bottleneck anyway.
• I/O multiplexing: epoll/kqueue lets that one thread service tens of thousands of concurrent connections; the network, not command execution, is the usual constraint. Redis 6 added I/O threads for socket reads/writes while keeping execution single-threaded.
• Purpose-built data structures and compact encodings (ziplist/listpack for small hashes and lists, intset, skiplist for sorted sets) that keep operations cheap and memory small.
• The flip side: one slow command blocks everything — KEYS *, big SORT, large Lua scripts — hence SCAN, and why O(N) commands on large keys are an outage waiting to happen.
• Scaling out: hash-slot partitioning in Redis Cluster, primary-replica replication for read scale and failover, and client-side or proxy-based sharding past a single node's ceiling.
• Background work: forked child processes for RDB snapshotting and AOF rewrite, and lazy freeing (UNLINK) so large deletes do not stall the loop.