Redis handles enormous request rates on one thread for command execution. That sounds backwards. Everyone is taught that more cores mean more throughput, so how does a single-threaded server outrun multithreaded databases? The answer is that Redis removed the two costs that usually dominate, disk and lock contention, and that changes what "fast" even means.
The core problem
Most databases spend their time on two things: waiting for disk, and coordinating threads that share data. Disk waits are slow by orders of magnitude compared to memory. Thread coordination means locks, and locks mean contention, context switches, and cache lines bouncing between cores. A multithreaded design fights these costs constantly, and a lot of engineering goes into fighting them.
Redis sidesteps both. Data lives in memory, so there is no disk in the hot path. And command execution runs on a single thread, so there are no locks around the data structures at all. If only one thread ever touches the data, you do not need to protect it. The problem "how do I coordinate many threads safely" disappears by never having many threads on the data.
Key design decisions
Keep everything in memory. Redis is an in-memory store. Reads and writes hit RAM, not disk. Persistence exists, through snapshots and an append-only log, but it happens in the background or on a schedule and is not on the critical path of a normal command. This is the single biggest reason for the speed: memory access is a different universe from disk seeks.
Run commands on one thread with an event loop. A single thread pulls ready connections from the operating system using an efficient event notification mechanism, executes each command to completion, and moves on. Because commands are short and there is no disk wait inside them, one thread churns through a very large number of them. No locks, no thread scheduling overhead, no cache-line ping-pong on shared data. Each command is effectively atomic because nothing else runs during it.
Use non-blocking I/O. The thread never sits idle waiting on one slow socket. The event loop asks the OS which sockets are ready and only touches those. Idle or slow clients do not stall the others.
Purpose-built data structures. Redis is not just key-value. It ships hashes, sorted sets, lists, sets, bitmaps, and more, each implemented for speed. A sorted set gives you ranked lookups in logarithmic time in memory, which is why leaderboards and rate limiters are one command instead of a query plan.
The trade-offs
Single-threaded execution means one slow command blocks everything. There is no other thread to make progress while a command runs, so a command that scans a huge collection freezes the whole server for its duration. The discipline this forces is to avoid expensive operations on large keys and to use cursor-based iteration instead of blocking scans.
In-memory storage trades durability and capacity for speed. Your dataset must fit in RAM, which is more expensive and more limited than disk, and a crash can lose whatever has not been persisted yet, depending on your persistence settings. You tune this by choosing between snapshotting and the append-only log, trading data safety against write overhead.
Single-threaded command execution also does not use extra cores for the data path. To use more cores you run more Redis instances and shard across them, pushing the parallelism up to the deployment level instead of inside one process. Newer versions do use extra threads for network I/O, but the command execution model stays single-threaded on purpose.
How the real system does it
The real design is memory-resident data, a single-threaded event loop over non-blocking sockets for command execution, atomic commands because nothing interleaves, and specialized data structures that turn common problems into single operations. Persistence and replication run around that hot path rather than inside it, and horizontal scale comes from sharding across instances.
The lesson worth keeping: threads are not the only path to speed. Removing the slow parts, disk and lock contention, can beat adding cores. Sometimes the fastest design is the one that does less coordination, not more.
I wrote the full breakdown, with diagrams and the data model, here: https://www.systemdesign.academy/interview/design-redis
Top comments (0)