"Redis is single-threaded, so why is it so fast?"
This is a flagship backend interview question at Alibaba, ByteDance, Meituan, and any company running high-QPS services. The interviewer is checking whether you actually understand where performance comes from — memory vs. disk, CPU-bound vs. I/O-bound, and kernel-level I/O primitives like epoll — rather than parroting "Redis is fast because it's in memory."
Reframe the question: Redis being fast is mostly independent of thread count. The bottleneck is network I/O and memory access, not CPU.
Explain the four real reasons: pure in-memory operations (~100ns), efficient data structures (skiplist, ziplist, quicklist), I/O multiplexing (epoll on Linux, kqueue on BSD), and no lock contention because everything runs on one thread.
Cover the command processing model: single event loop pulls ready FDs from epoll, executes commands atomically, sends replies — so commands are naturally serialized without locks.
Mention the Redis 6 change: the main command executor is still single-threaded, but network I/O (reading/writing from sockets, parsing protocol) was split into a worker thread pool to handle connection scaling. Command execution itself is still serial.
Flag the limits: Redis is slow when commands are CPU-heavy (KEYS *, large LRANGE, Lua scripts), or when a single key is huge (big key problem). Single-threaded means one slow command blocks everything.
The question is slightly misleading — Redis is fast despite being single-threaded, not because of it. The real reasons are: first, all data lives in memory, so a typical read/write takes around 100 nanoseconds versus milliseconds for disk. Second, Redis picks the optimal internal encoding per data type — a small hash is stored as a ziplist for cache locality, a large one converts to a hashtable; sorted sets use a skiplist for O(log n) range queries. Third, Redis uses I/O multiplexing — one thread waits on thousands of client sockets with epoll on Linux, and only wakes up for ready file descriptors. This avoids the cost of per-connection threads and context switches. Fourth, the single-threaded command executor means no locks, no CAS loops, no cache-line bouncing across CPUs. Every command is atomic because nothing else can run concurrently. The tradeoff is that single-threaded execution means one slow command (KEYS * on a million-key DB, a 10MB HGETALL, or a long Lua script) blocks every other client. That's why production Redis usage bans KEYS and prefers SCAN. Redis 6 added multi-threaded I/O for the network layer specifically — reading bytes off sockets and writing responses can now parallelize across worker threads, but the actual command execution is still single-threaded on the main thread to preserve the atomicity guarantee. So it's best thought of as a single-threaded core with a multi-threaded I/O frontend.
Never say "Redis is fast because it's in memory" and stop there — interviewers expect the epoll + single-threaded atomicity + data structure layer.
Be ready to name specific problem commands: KEYS, FLUSHALL, large LRANGE/HGETALL, SMEMBERS on big sets.
Know the Redis 6 multi-threading nuance — getting it wrong signals you haven't touched recent versions.
During a real interview, use HireMe AI to surface talking points like epoll, ziplist, and big-key issues when your memory blanks.
Only for network-bound workloads with many connections — which is exactly what Redis 6 addressed. For CPU-bound command execution, multi-threading would introduce lock overhead that would likely hurt throughput.
No. Complex Lua scripts or aggregations on large datasets should be done in the application layer. A single slow Redis command freezes the whole server.
Run multiple Redis instances per machine (each pinned to a core), use Redis Cluster for sharding, or use read replicas to offload reads.
HireMe AI listens to your interview in real-time, detects questions, and generates instant answer suggestions — so you never freeze up again.
Try HireMe AI Free