How does Redis achieve high throughput with a mostly single-threaded design?

Redis's core command execution has traditionally run on a single thread, which sounds like it should limit throughput, but it actually sidesteps a large class of overhead that a multi-threaded design would otherwise need to pay for.

• No lock contention — since only one thread ever touches the core data structures at a time, there's no need for mutexes or locking around reads and writes, which removes a meaningful source of overhead multi-threaded in-memory stores have to manage.
• In-memory operations are already fast — most commands complete in microseconds, so a single thread can still issue an enormous number of operations per second.
• Efficient event-driven networking — the server uses an event loop over multiplexed I/O to handle many client connections concurrently on that one thread, rather than blocking per connection.
• Predictable atomicity — because commands run one at a time with nothing else interleaved, individual commands (and MULTI/EXEC transactions) are naturally atomic with no extra coordination needed.

Modern Redis does offload some genuinely parallelizable work — like background persistence via a forked child process, and I/O threading for reading/writing client sockets in newer versions — to separate threads/processes, while keeping command execution itself single-threaded. This hybrid approach is what lets Redis claim both simplicity/atomicity and very high real-world throughput at the same time.