Why Can Redis Handle Over 100k QPS? A Deep Technical Breakdown

Introduction

A recent interview asked: "Why can Redis support 100k+ QPS?" The simple answer "because it is an in‑memory database" is insufficient; the interviewer expects a deeper technical explanation.

1. What Does 100k+ QPS Mean?

Official benchmark results on a typical laptop:

GET: ~103,504 QPS

SET: ~100,894 QPS

INCR: ~99,662 QPS

When pipeline is enabled, INCR QPS can jump to 1,061,301 , breaking the million‑QPS barrier.

2. Pillar One – Memory Is King

All Redis data resides in memory. A single memory access costs about 0.1 µs, while a random disk I/O takes around 10 ms – memory is roughly 100,000 times faster than disk.

Example comparison : Querying an ID among 10 million users.

MySQL (even with an index) needs 2–3 disk I/Os (20–30 ms).

Redis performs an in‑memory hash lookup in about 0.1 ms.

This illustrates the magnitude of the speed gap.

3. Pillar Two – Extreme Data Structures

Redis provides five core data structures: string, hash, list, set, and sorted set. Each is heavily tuned for its use case.

3.1 Simple Dynamic String (SDS)

struct sdshdr {
    int len;   // used length
    int free;  // unused length
    char buf[]; // byte array
}

O(1) length : length stored directly in len.

Buffer overflow protection : before modification, remaining space is checked; if insufficient, the buffer expands automatically.

Space pre‑allocation : extra free space is allocated during expansion to reduce reallocations.

3.2 Ziplist (Compressed List)

When a hash or list contains few elements and small values, Redis stores them in a contiguous memory block called a ziplist. This eliminates pointer overhead and makes better use of CPU caches.

Advantages : memory‑compact and fast access.

Conditions : automatically used when element count < 512 and value length < 64 bytes.

3.3 Skip List

The ordered set (ZSET) is implemented partly with a skip list, a multi‑level linked list offering O(log N) lookup while being simpler than balanced trees.

During a search, the algorithm starts from the highest level and jumps forward, achieving very high efficiency.

3.4 Incremental Rehash

When Redis expands a hash table, it does not move all entries at once. Instead, it migrates entries gradually across subsequent operations, spreading the cost and avoiding service pauses.

4. Pillar Three – Single Thread + I/O Multiplexing

Redis processes network requests with a single core thread.

CPU is not the bottleneck : memory operations are extremely fast, leaving little idle time for the CPU.

No lock contention : the single thread eliminates synchronization overhead.

I/O multiplexing : the thread uses epoll to monitor thousands of connections and only handles events when they occur.

This design gives Redis high concurrency while keeping the core logic simple and reliable.

5. Pillar Four – From Single Thread to Multi‑Core Utilization

Before Redis 6.0, both network I/O and command execution were single‑threaded, which could become a bottleneck under heavy traffic. Redis 6.0 introduced I/O multithreading:

IO read : multiple threads read client requests and parse the protocol in parallel.

Command execution : the main thread still executes commands sequentially, guaranteeing atomicity.

IO write : multiple threads write responses back to clients concurrently.

This architecture fully exploits multi‑core CPUs for network handling while keeping the command execution path simple.

6. Other Performance Boosters

Pipeline batch operations : send many commands in one round‑trip to reduce network latency.

Jedis jedis = new Jedis("localhost");
Pipeline p = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
    p.incr("counter");
}
p.sync();

Avoid large keys : keys larger than 10 KB can block the service. Use redis-cli --bigkeys to detect them.

Reasonable persistence : during load testing, disable persistence (RDB/AOF) to avoid interference.

7. Advantages, Disadvantages, and Suitable Scenarios

Advantages : extremely high performance (100k+ QPS), rich data structures, persistence guarantees, high‑availability clustering.

Disadvantages : high memory cost, single‑threaded command path can block, limited capacity per node, risk of large keys.

Suitable scenarios : cache acceleration, real‑time counters, distributed locks, leaderboards/social feeds.

Conclusion

Redis achieves 100k+ QPS through the combined effect of four pillars:

In‑memory storage eliminates disk I/O.

Optimized data structures (SDS, ziplist, skip list, incremental rehash) reduce overhead.

Single‑threaded event loop with epoll‑based I/O multiplexing avoids lock contention.

Optional multi‑threaded I/O in Redis 6.0 leverages multi‑core CPUs for network throughput while keeping command execution simple.

Understanding the “what” and the “why” behind these mechanisms helps you design and tune high‑performance systems with Redis.