Why Is Redis So Fast? Inside Its Data Structures and Single‑Threaded Design

Why Redis Is Fast

Redis delivers rapid query performance because it is an in‑memory database, uses highly optimized data structures, runs a single‑threaded event loop, and employs I/O multiplexing.

Core Data Structures

Simple Dynamic Strings (SDS) replace C char arrays. An SDS header stores the used length ( len ) and free space ( free ) along with the character buffer ( char buf[] ). This enables O(1) length retrieval, prevents buffer overflows, and allows automatic space expansion.

<code>struct sdshdr {
    long len;   // used bytes
    long free;  // unused bytes
    char buf[]; // string data
};</code>

SDS also uses pre‑allocation for small modifications and lazy free for shrinking, supports binary data, and remains compatible with many C string functions.

Linked List – Redis lists are implemented with doubly linked lists when they contain many or long elements.

Dictionary (hash table) – Each Redis database has a primary dict for key‑value pairs and an expires dict for TTL information. All lookups pass through a hash table, which resolves collisions via chaining and uses progressive rehashing with two hash tables (HT1 and HT2) to avoid blocking.

Skip List – Sorted sets (zset) are built on skip lists, providing O(log N) search by maintaining multiple forward pointers per node.

Integer Set (intset) – Used for sets containing only integers; it stores values as 16/32/64‑bit integers and upgrades when larger integers are added.

Compressed List (ziplist) – Used for small lists and hashes. It stores entries compactly with fields such as zlbytes , zltail , zllen , and entry . Modifications may trigger chain updates because length fields must be resized.

Single‑Threaded Model and I/O Multiplexing

Redis processes all commands in a single thread, eliminating lock contention. Network I/O is handled via multiplexing (epoll, kqueue, or select), allowing one thread to manage many sockets efficiently.

While the command execution remains single‑threaded, Redis 6.0 introduced optional multi‑threaded I/O for client read/write, keeping the event‑loop thread for command processing.

Performance Bottlenecks

Potential slowdowns include big keys, high‑complexity commands, massive key expirations, eviction processing, AOF fsync on every write, and full RDB snapshots that fork a child process. Redis 4.0 added lazy‑free for big‑key deletion, and Redis 6.0 added multi‑threaded I/O to mitigate network‑I/O limits.

Conclusion

By combining in‑memory storage, efficient data structures (hash tables, skip lists, SDS, ziplists), a single‑threaded design with I/O multiplexing, and progressive rehashing, Redis achieves the high performance that makes it a popular choice for caching and real‑time data processing.