Why Is Redis So Fast? Deep Dive into Its History, Architecture, and Performance

Introduction

Redis is an open‑source, in‑memory data‑structure store. Its design—memory‑first implementation, specialized data structures, adaptive encoding, and an event‑driven single‑threaded network model—delivers sub‑millisecond latency and high throughput.

Version Timeline

May 2009 – Redis 1.0 (initial release)

2012 – Redis 2.6.0

Nov 2013 – Redis 2.8.0

Apr 2015 – Redis 3.0.0 (added clustering)

Jul 2017 – Redis 4.0.0 (added module system)

Oct 2018 – Redis 5.0.0 (added Streams)

May 2020 – Redis 6.0.1 (multi‑threaded I/O, RESP3, disk‑less replication)

Jan 2022 – Redis 7.0 RC1 (performance and memory optimizations, new AOF mode)

Performance Benchmarks

Redis ships with the redis-benchmark utility, which can simulate thousands of concurrent clients. Official tests show that Redis can sustain over 50 000 commands per second (QPS) with more than 60 000 simultaneous connections. Throughput scales with the number of connections, but an instance with 30 000 connections processes roughly half the throughput of one with 100 connections, illustrating the impact of connection count on performance.

Key Architectural Factors

Memory‑First Implementation All data resides in RAM, eliminating disk I/O latency. This contrasts with disk‑based databases that must fetch data from storage.

Efficient Data Structures Redis uses purpose‑built structures for each data type:

SDS (Simple Dynamic String) : Stores length in the header, providing O(1) length retrieval and automatic resizing.

embstr & raw : Short strings (≤44 bytes) use the compact embstr layout; longer strings fall back to raw.

Dictionary (hash table) : Provides O(1) key lookup. The core C definition is:

typedef struct dict {</code><code>    dictType *type;</code><code>    void *privdata;</code><code>    dictht ht[2];</code><code>    long rehashidx; // progressive rehash position</code><code>} dict;

Ziplist : A contiguous memory block used for small lists, hashes, and sorted sets to save space.

Skiplist : Multi‑level linked structure enabling average O(log N) lookups for sorted sets.

Smart Encoding Redis selects the most space‑efficient encoding based on size and type: int for numeric strings embstr for short strings (≤44 bytes) raw for longer strings ziplist for small collections skiplist for large sorted sets

Thread Model and I/O Multiplexing Redis runs a single network thread that handles all client connections using the epoll/kqueue event loop, avoiding context‑switch overhead. Optional background threads manage persistence and eviction. This design allows a single thread to efficiently manage tens of thousands of sockets.

Data Encoding Details

When a string is stored, Redis chooses: int if the string represents a number embstr if the length ≤44 bytes (fits in L1 cache line) raw otherwise

For collections, Redis uses: ziplist when the number of elements is ≤512 and each element ≤64 bytes hashtable (dictionary) for larger hashes linkedlist for long lists skiplist for sorted sets with many elements

Thread Model and I/O Multiplexing

Redis’s single‑threaded network loop processes events (read, write, close) via epoll/kqueue, converting each event into a callback without blocking. This I/O multiplexing enables high concurrency with minimal CPU overhead.

Typical Use Cases

Caching layer for frequently accessed data

Real‑time analytics and leaderboards

Message queues and pub/sub systems

Session storage for web applications

Conclusion

Redis achieves its remarkable performance through a combination of pure in‑memory operations, an event‑driven single‑threaded network architecture, carefully engineered data structures (SDS, dictionary, ziplist, skiplist), and adaptive encodings. Understanding these mechanisms helps developers avoid patterns that could degrade performance.