Why Redis Is So Fast: Inside Its Memory Design and Data Structures

In‑Memory Architecture

Redis stores all data directly in RAM, avoiding the disk I/O bottleneck that traditional disk‑based databases face. Because the data never needs to be read from disk, operations are dramatically faster.

Efficient Data Structures

Redis supports multiple data types, each backed by one or more optimized structures:

1. Simple Dynamic Strings (SDS)

SDS replaces the naive C string implementation. It stores the string length in a dedicated len field, allowing O(1) length queries instead of O(n) scans for a terminating \0. SDS also uses two memory‑saving strategies:

Pre‑allocation : When a string grows, Redis allocates extra unused space (equal to the current length if len < 1 MiB, otherwise a fixed 1 MiB) to reduce future reallocations.

Lazy free : Shrinking a string does not immediately release memory; the freed space is recorded in a free field and reused on subsequent expansions.

These tricks keep both time and space overhead low.

2. Doubly Linked List (List)

Lists are implemented as doubly linked lists, giving O(1) access to both previous and next nodes. The list header stores head, tail, and len, so length queries are also O(1).

3. Ziplist (Compressed List)

When a list element is very small (e.g., a single byte), storing a full node would waste memory. Ziplist stores elements in a contiguous memory block with a custom encoding, reducing both space and traversal cost.

4. Dictionary (Hash Table)

All key‑value pairs in Redis are kept in a hash table, providing O(1) average‑case lookup and insertion.

5. Skiplist (Sorted Set)

Sorted sets use a multi‑level linked structure called a skiplist. Each level is an ordered list, allowing O(log N) search while keeping memory usage modest.

Reasonable Data Encoding

Redis chooses the most suitable internal encoding based on the size and type of the data:

String : Integers are stored with an int encoding; non‑numeric strings use raw encoding.

List : Small lists become ziplists; larger ones become linked lists.

Hash : Small field/value strings use a ziplist‑like encoding; otherwise a hash table.

Set : Integer elements use an intset; otherwise a hash table.

Zset : Small sorted sets become ziplists; larger ones use skiplists.

Suitable Thread Model

Redis gains additional speed from its single‑threaded, event‑driven architecture:

1. I/O Multiplexing

Redis uses an event loop that monitors many client sockets simultaneously (e.g., via epoll or select). Incoming commands are queued and processed one by one, eliminating the overhead of thread synchronization.

2. Avoiding Context Switches

Because all operations run in a single OS thread, Redis avoids costly CPU context switches that multi‑threaded servers incur. Memory accesses stay on the same core, maximizing cache locality.

3. Reactor Model

Requests are placed into a queue, handed to a file‑event dispatcher, and processed by the same thread. This design keeps the processing pipeline simple and fast.

Summary

In‑memory storage removes disk I/O latency.

Specialized data structures (SDS, doubly linked list, ziplist, hash table, skiplist) provide O(1) or O(log N) operations.

Adaptive encoding selects the most efficient representation for each data type.

A single‑threaded, I/O‑multiplexed event loop eliminates context‑switch overhead.

These combined techniques explain why Redis can handle millions of operations per second with minimal latency.