Why Redis Is Fast: Core Principles, Data Structures, and Architecture

Redis is renowned for its speed, and this article explores the fundamental reasons behind its performance, covering the memory‑first design, core data structures, single‑threaded execution model, and I/O multiplexing.

Redis Panorama

The system can be viewed from two dimensions: the application dimension (caching, clustering, clever use of data structures) and the system dimension, which focuses on three "high" qualities:

High performance – thread model, network I/O model, data structures, persistence mechanisms.

High availability – master‑slave replication, Sentinel, Cluster sharding.

High scalability – load balancing.

Why Redis Is Fast

Beyond the well‑known fact that Redis stores data entirely in memory, its speed stems from several deeper optimizations:

All read/write operations happen in RAM, avoiding disk I/O bottlenecks.

A global hash table provides O(1) key lookup; rehashing is performed incrementally to prevent blocking.

Specialized data structures (SDS, ziplist, quicklist, skiplist, intset) are chosen per data type to minimize memory footprint and access time.

The server runs a single thread for command execution, eliminating context‑switch overhead and lock contention.

Non‑blocking I/O is achieved with an epoll‑based event loop, allowing one thread to handle thousands of connections concurrently.

Pure In‑Memory Implementation

Redis stores every key‑value pair in a global hash table. The hash table’s average lookup time is O(1) because the hash of a key directly yields the bucket index.

When hash collisions occur, Redis uses chained hashing and performs incremental rehashing:

Allocate a larger second hash table.

Gradually move entries from table 1 to table 2 during normal request processing.

Release the old table once migration completes.

Efficient Data Structures

Simple Dynamic String (SDS)

SDS stores the string length explicitly, enabling O(1) length queries, pre‑allocation of unused space, lazy free of trimmed bytes, and binary‑safety.

struct ziplist<T> {
    int32 zlbytes;          // total bytes of the ziplist
    int32 zltail_offset;   // offset of the last entry
    int16 zllength;         // number of entries
    T[] entries;            // compact array of entries
    int8 zlend;            // end marker (0xFF)
}

ziplist (Compressed List)

Used for small lists, hashes, and sorted sets; stores entries in a contiguous memory block with three header fields (zlbytes, zltail, zllen). Lookup of the first or last element is O(1); other lookups are O(N).

quicklist

Combines linked‑list nodes with ziplist segments, providing fast head/tail operations while keeping memory compact.

skiplist

Implements the ordered set (Zset) using multiple forward pointers per node, achieving average O(log N) search time.

intset (Integer Set)

typedef struct intset {
    uint32_t encoding;   // integer encoding (16/32/64 bit)
    uint32_t length;    // number of elements
    int8_t contents[];  // sorted array of integers
} intset;

Object Encoding

Redis objects (redisObject) contain type, encoding, and a pointer to the underlying data structure. Depending on size and content, each data type may be stored using different encodings (raw vs. int for strings, ziplist vs. hashtable for hashes, etc.).

Single‑Threaded Model

Redis executes network I/O and command processing in a single thread, while persistence, replication, and background deletions run in auxiliary threads. The single thread avoids context‑switch overhead, lock contention, and simplifies code.

I/O Multiplexing

Redis uses epoll‑based I/O multiplexing to monitor many sockets with one thread. Accept and recv calls are non‑blocking; the event loop dispatches ready events to the command processor, allowing thousands of concurrent client connections without blocking.

Summary of the "Fast and Unbreakable" Principles

All operations are performed in memory, eliminating disk I/O latency.

A global hash table provides O(1) lookups; incremental rehashing prevents pauses.

Non‑blocking I/O with epoll enables a single thread to serve many clients.

The single‑threaded design guarantees atomicity and removes lock overhead.

Specialized data structures (hash table, SDS, ziplist, quicklist, skiplist, intset) optimize storage and access for each data type.

Adaptive encoding selects the most efficient representation based on data size and type.