How Redis achieves sub-millisecond latency - Mechanics & Internals

Overview - How Redis achieves sub-millisecond latency

What is it?

Redis is a fast, in-memory database that stores data in a way that allows it to respond to requests very quickly, often in less than a millisecond. It keeps all data in memory instead of on disk, which makes reading and writing data extremely fast. Redis uses simple data structures and efficient commands to handle many operations quickly. This speed helps applications respond instantly to user actions or system events.

Why it matters

Fast response times are crucial for many applications like gaming, real-time analytics, and messaging. Without Redis's speed, these applications would feel slow or laggy, frustrating users and reducing effectiveness. Redis solves the problem of slow data access by keeping data ready in memory and using smart techniques to avoid delays. Without Redis, developers would struggle to build fast, scalable systems that handle many users at once.

Where it fits

Before learning how Redis achieves sub-millisecond latency, you should understand basic database concepts like data storage, memory vs disk, and client-server communication. After this, you can explore Redis's advanced features like persistence, clustering, and Lua scripting to see how it balances speed with reliability and scalability.

Mental Model

Core Idea

Redis achieves sub-millisecond latency by keeping data in memory and using simple, efficient operations that avoid delays.

Think of it like...

Imagine a chef who keeps all ingredients on the kitchen counter instead of in the fridge, so they can cook dishes instantly without waiting to fetch anything.

┌───────────────┐
│ Client Request│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Redis Server  │
│  In-Memory DB │
│  Simple Ops   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Instant Reply │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

In-memory data storage basics

Concept: Redis stores all data in the computer's memory (RAM) instead of on slower disk drives.

Most traditional databases save data on disks, which take time to read and write. Redis keeps data in RAM, which is much faster to access. This means Redis can find and return data almost instantly because it doesn't have to wait for slow disk operations.

Result

Data retrieval and updates happen in microseconds, enabling very fast responses.

Understanding that memory is much faster than disk is key to why Redis can be so quick.

2

Foundation

Simple data structures and commands

Concept: Redis uses simple, efficient data types and commands to minimize processing time.

Redis supports basic data types like strings, lists, sets, and hashes. Each command operates directly on these types with minimal overhead. For example, getting a value by key is a direct memory lookup, which is very fast compared to complex queries.

Result

Commands execute quickly because they do little extra work beyond accessing memory.

Knowing that simple operations reduce processing delays helps explain Redis's speed.

3

Intermediate

Single-threaded event loop model

🤔Before reading on: do you think Redis uses multiple threads to handle many requests at once or a single thread? Commit to your answer.

Concept: Redis uses a single-threaded event loop to process commands sequentially without locking overhead.

Unlike many databases that use multiple threads and locks, Redis processes one command at a time in a fast loop. This avoids delays caused by thread switching or waiting for locks. The event loop listens for requests, processes them quickly, and sends responses without interruption.

Result

Redis achieves predictable, low latency by avoiding complex concurrency issues.

Understanding that single-threaded design avoids costly synchronization explains how Redis keeps latency low.

4

Intermediate

Non-blocking I/O and networking

🤔Before reading on: do you think Redis waits for each network request to finish before starting the next, or handles many at once? Commit to your answer.

Concept: Redis uses non-blocking input/output to handle many client connections efficiently.

Redis uses an event-driven model where it does not wait for network operations to complete before moving on. This means it can manage thousands of clients by quickly switching between them without delays. It reads requests and writes responses asynchronously, keeping the server responsive.

Result

Redis can serve many clients with minimal delay, maintaining sub-millisecond latency.

Knowing how non-blocking I/O works clarifies how Redis scales without slowing down.

5

Intermediate

Efficient memory management

Concept: Redis uses optimized memory allocation and data encoding to reduce overhead.

Redis carefully manages memory by using compact data structures and reusing memory efficiently. It avoids fragmentation and uses techniques like lazy freeing to prevent pauses. This keeps memory access fast and consistent.

Result

Memory operations do not cause noticeable delays, supporting fast command execution.

Understanding memory management helps explain how Redis avoids hiccups that slow other systems.

6

Advanced

Persistence without latency impact

🤔Before reading on: do you think saving data to disk always slows Redis down? Commit to your answer.

Concept: Redis saves data to disk asynchronously to avoid slowing down command processing.

Although Redis keeps data in memory, it can save snapshots or logs to disk for durability. It does this in the background without blocking the main event loop. This means Redis can persist data safely without affecting its fast response times.

Result

Redis combines speed with data safety, avoiding latency spikes during saves.

Knowing how asynchronous persistence works reveals how Redis balances speed and reliability.

7

Expert

Optimizations in command execution pipeline

🤔Before reading on: do you think Redis parses and executes commands in multiple steps or a streamlined process? Commit to your answer.

Concept: Redis uses a highly optimized pipeline to parse, execute, and respond to commands with minimal overhead.

Redis parses incoming commands quickly using a simple protocol, executes them directly on memory, and sends responses immediately. It minimizes copying data and uses efficient buffers. This streamlined pipeline reduces CPU cycles and latency.

Result

Commands complete in microseconds, enabling sub-millisecond latency even under load.

Understanding the command pipeline optimization explains how Redis maintains speed at scale.

Under the Hood

Redis operates as a single-threaded server that keeps all data in RAM. It uses an event loop to handle client requests one at a time, avoiding locks and context switches. Network I/O is non-blocking, allowing Redis to serve many clients efficiently. Commands are parsed and executed in a streamlined pipeline that minimizes CPU and memory overhead. Persistence is handled asynchronously to avoid blocking the main loop. Memory is managed with compact data structures and lazy freeing to prevent pauses.

Why designed this way?

Redis was designed to maximize speed by avoiding traditional database bottlenecks like disk access, locking, and complex query parsing. The single-threaded model was chosen to simplify concurrency and reduce overhead. Non-blocking I/O and asynchronous persistence were added to scale to many clients without sacrificing latency. These design choices trade off some features for extreme speed, fitting use cases that need fast data access.

┌───────────────┐
│ Client Socket │
└──────┬────────┘
       │
       ▼
┌─────────────────────┐
│ Event Loop (Single   │
│ Thread)             │
│ ┌─────────────────┐ │
│ │ Command Parsing │ │
│ ├─────────────────┤ │
│ │ Command Exec    │ │
│ └─────────────────┘ │
└──────┬──────────────┘
       │
       ▼
┌───────────────┐
│ In-Memory DB  │
│ (RAM Storage) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Async Persistence│
│ (Disk Saving)    │
└─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Redis use multiple CPU cores to achieve its speed? Commit to yes or no.

Common Belief: Redis uses multiple CPU cores simultaneously to handle many requests fast.

Reality: Redis is mostly single-threaded and uses one core at a time for command processing.

Why it matters: Believing Redis is multi-threaded can lead to wrong assumptions about scaling and performance tuning.

Quick: Does saving data to disk always slow Redis down? Commit to yes or no.

Common Belief: Whenever Redis saves data to disk, it causes noticeable delays and latency spikes.

Reality: Redis saves data asynchronously in the background, so persistence usually does not affect latency.

Why it matters: Misunderstanding this can cause unnecessary fear about using persistence features.

Quick: Is Redis slow when many clients connect at once? Commit to yes or no.

Common Belief: Redis slows down significantly when handling thousands of clients simultaneously.

Reality: Redis uses non-blocking I/O and an event loop to efficiently manage many clients without slowing down.

Why it matters: Assuming Redis can't handle many clients may prevent its use in high-traffic applications.

Quick: Does Redis perform complex query parsing like SQL databases? Commit to yes or no.

Common Belief: Redis parses and executes complex queries similar to traditional SQL databases.

Reality: Redis uses simple commands on basic data types, avoiding complex query parsing overhead.

Why it matters: Expecting complex queries can lead to inefficient use or disappointment with Redis capabilities.

Expert Zone

1

Redis's single-threaded model means that long-running commands can block all other clients, so command design matters deeply.

2

Memory fragmentation is minimized by Redis's use of jemalloc and lazy freeing, which prevents latency spikes.

3

The RESP protocol used by Redis is designed for minimal parsing overhead, contributing significantly to speed.

When NOT to use

Redis is not ideal for workloads requiring complex multi-key transactions, heavy disk-based storage, or strong ACID guarantees. In such cases, traditional relational databases or distributed NoSQL systems like Cassandra or PostgreSQL are better choices.

Production Patterns

In production, Redis is often used as a cache layer in front of slower databases, a message broker, or a real-time analytics engine. Techniques like pipelining commands, sharding data across multiple Redis instances, and using Lua scripts for atomic operations are common to maintain low latency at scale.

Connections

Event-driven programming

Redis's single-threaded event loop is a direct application of event-driven programming.

Understanding event-driven programming helps grasp how Redis handles many clients efficiently without multi-threading.

Operating system memory management

Redis's performance depends on how the OS manages RAM and allocates memory.

Knowing OS memory behavior explains why Redis uses specific allocators and lazy freeing to avoid latency spikes.

Real-time systems engineering

Redis shares goals with real-time systems: predictable, low-latency responses.

Studying real-time systems principles helps understand Redis's design choices to guarantee sub-millisecond latency.

Common Pitfalls

#1 Blocking commands cause latency spikes

Wrong approach:

Using commands like KEYS * or large SORT operations in production.

Correct approach:

Use SCAN for incremental iteration and avoid large blocking commands.

Root cause:

Misunderstanding that some commands block the single thread, delaying all clients.

#2 Expecting Redis to scale automatically on multiple cores

Wrong approach:

Running a single Redis instance on a multi-core server expecting linear speedup.

Correct approach:

Use Redis Cluster or multiple instances to scale across cores.

Root cause:

Not knowing Redis is single-threaded and requires sharding for multi-core scaling.

#3 Disabling persistence to improve speed without understanding risks

Wrong approach:

Turning off RDB and AOF persistence to get faster responses.

Correct approach:

Use asynchronous persistence and tune save intervals to balance speed and durability.

Root cause:

Believing persistence always causes slowdowns and ignoring data loss risks.

Key Takeaways

Redis achieves sub-millisecond latency by storing all data in memory and using simple, efficient commands.

Its single-threaded event loop avoids locking overhead, providing predictable and fast command processing.

Non-blocking I/O allows Redis to handle many clients simultaneously without delays.

Asynchronous persistence ensures data durability without impacting response times.

Understanding Redis's design helps use it effectively and avoid common performance pitfalls.