If Redis is single-threaded, how does it handle so many requests?

Redis is not fast because it uses many threads. It is fast because it does not wait: one event loop, data in RAM, and no thread-per-request tax.

If Redis is single-threaded, how does it handle so many requests?

The interview question sounds like a trap.

If Redis is single-threaded, how does it handle millions of requests per second?

The usual mental model is: one request, one thread. Ten thousand connections means ten thousand threads, plus the cost of switching between them and locking shared data.

Redis does not work that way.

What Redis actually does

Command processing runs on one main thread and one event loop.

There are no locks around the dataset for that path. There is no pool of idle workers waiting on disk.

The data lives in memory. A RAM read is on the order of a hundred nanoseconds. A disk read is milliseconds. That gap is the whole game.

Instead of spawning a thread per connection, Redis asks the operating system to signal when a socket is ready. While one client is waiting on the network, Redis is already serving another.

That is I/O multiplexing. It is why a single Redis instance can keep thousands of connections busy without looking “multithreaded.”

A practical picture

Your API does GET user:42.

Redis does not park a worker on that key. It reads from RAM, writes the reply, and moves to the next ready client. The expensive part — waiting on the network — is not charged to a blocked thread.

Newer Redis versions can use extra threads for some network I/O. The important part for interviews and production is unchanged: the data path is still a single-threaded event loop over an in-memory store.

Takeaway

Redis is fast because it refuses the thread-per-request model.

One loop. Data in RAM. No waiting on disk for the common case.

If you remember why, you can reason about when Redis will *not* be fast: huge values, slow commands that block the loop, or treating it like a disk database.