Why Is Redis So Fast? Deep Dive into Its Architecture and Persistence

Overview

When people hear "Redis" they often think of a cache, but Redis can also serve as a rate limiter, message broker, and full‑featured database. This article explores what Redis is, why it is exceptionally fast, and how to use it effectively.

Basics

Cache is like keeping frequently used items on your desk instead of fetching them from a storage room. Redis acts as a high‑speed in‑memory data store, keeping all data in RAM rather than on slower disks, which eliminates the disk I/O bottleneck.

Why Is Redis So Fast?

Three main factors give Redis its speed:

In‑memory data storage – Accessing RAM is orders of magnitude faster than SSD or NVMe, with latency measured in nanoseconds.

Single‑threaded command execution – All commands run on one thread, avoiding lock contention, context switches, and other multithreading overhead.

Highly optimized C code and data structures – Redis is written in ANSI C and uses custom structures such as SDS (simple dynamic strings) and specialized encodings for hashes and sets, minimizing memory usage and CPU cycles.

Single‑Threaded Feature

Redis processes commands in a single thread using an event‑driven architecture with I/O multiplexing (epoll, kqueue, or IOCP). The main thread runs an event loop that watches many sockets simultaneously.

Analogy: you are the only chef who can cut ingredients (the single thread), while many assistants (the OS kernel) notify you when a pot is ready. You pause cutting, handle the pot, then resume cutting.

The actual process looks like:

Event loop registers all client sockets with the multiplexing API.

The API notifies the loop only when a socket is ready for I/O (e.g., client sent data).

The thread reads the command, parses it, executes it, and writes the response back.

This non‑blocking I/O model keeps the thread busy, providing high throughput and concurrency.

Persistence

Redis offers two complementary persistence mechanisms to store the in‑memory dataset on non‑volatile storage.

RDB (Redis Database)

RDB creates point‑in‑time snapshots by forking a child process that writes the entire dataset to a compact binary .rdb file. It is CPU‑ and I/O‑efficient, ideal for backups and fast restarts, but may lose data written after the last snapshot if a crash occurs.

AOF (Append‑Only File)

AOF logs every write command to appendonly.aof. On restart, Redis replays the logged commands to rebuild the dataset. The appendfsync setting controls durability:

Always – sync after every write (slowest, safest).

Every second – sync once per second (default, balances speed and safety, up to 1 second of data loss).

Never – let the OS decide when to flush (fastest, least safe).

AOF can be rewritten in the background to prevent unlimited growth, creating a minimal command set for the current dataset and atomically replacing the old file. In production, many teams enable both AOF (for near‑real‑time durability) and RDB (for periodic backups).

Practical Use Cases

“Redis is widely used as a cache layer.”

Example: a web app caches user profile data in Redis. On a request, the app checks Redis first; a cache hit returns data instantly, while a miss triggers a fetch from MySQL, stores the result in Redis with a TTL (e.g., 15‑20 minutes), and returns it.

“Redis can also serve as a primary database for latency‑sensitive applications, such as game leaderboards.”

For a real‑time leaderboard, store player scores in a sorted set and retrieve the top 10 with: ZREVRANGE leaderboard 0 9 Redis persists this data via RDB or AOF as needed.

Memory Management

Redis achieves memory efficiency through custom data structures and dynamic encoding.

It uses SDS (simple dynamic strings) instead of null‑terminated C strings. SDS stores the length in the header, giving O(1) length lookup and reducing the need to scan the string.

When an SDS grows, Redis allocates extra space to avoid frequent reallocations.

Redis also switches internal encodings based on data size and content:

Small hash tables may be encoded as ziplist (or listpack) to store all entries in a single contiguous block.

Sets of only integers can use intset, a compact sorted array.

Small sorted sets can also be encoded as ziplist.

These strategies keep memory overhead low while maintaining fast access.