How Redis Achieves 500K QPS on a Single Instance: Memory, Single‑Threading, and Multiplexing

High‑Performance Memory

Redis stores all data in RAM, which provides access latency around 100 ns, far faster than mechanical disks (≈10 ms) or SSDs (0.1‑1 ms). In a high‑traffic e‑commerce flash‑sale scenario, reading product inventory from Redis is a simple memory address operation, while a MySQL query may still involve disk I/O or complex buffer‑pool scheduling. Because Redis operations run in O(1) or O(log N) time, a single Redis instance can handle well over 100 k requests per second.

High‑Performance Thread Model

Redis uses a single‑threaded model for core data operations, which many readers mistakenly think limits performance. In reality, only the main thread processes commands such as GET and SET, avoiding lock contention, context switches, and complex concurrency control. When many GET/SET requests arrive simultaneously, the main thread handles them sequentially without creating a thread per request, making it faster than a multi‑threaded approach with locking for simple caching workloads. Auxiliary tasks like AOF/RDB persistence and asynchronous deletion are offloaded to background threads.

High‑Performance I/O with Multiplexing

Redis employs non‑blocking I/O using the epoll mechanism on Linux. Epoll allows a single thread to monitor thousands of file descriptors, converting network connections into events such as Accept, Read, and Write. When data arrives on a connection, the kernel notifies Redis, and the main thread processes the event.

while (true) {
    events = epoll_wait();
    for event in events:
        if readable:
            read data;
        if writable:
            write response;
}

This event‑driven design eliminates the need for a thread per connection and avoids blocking waits, enabling rapid switching and batch processing of ready events. It is especially suited for high‑concurrency short‑request workloads, allowing Redis to serve a massive number of clients with minimal resources.