Introduction

Redis stands for Remote DIctionary Server. It is an open-source, in-memory data structure store that can be used as:

1. Database (stores data in memory with optional persistence to disk)
2. Cache (fast retrieval of frequently accessed data)
3. Message broker (publish/subscribe, streaming, and queueing system)

Redis is known for speed because it stores data in RAM instead of slower disk storage. It can perform hundreds of thousands of operations per second.

Features

Feature	Description
In-memory storage	Data is stored in RAM, making reads/writes extremely fast.
Persistence	Optionally saves data to disk via RDB snapshots or AOF logs.
Data structures	Beyond simple key-value, supports rich types like lists, sets, and hashes.
Pub/Sub messaging	Enables event-driven applications with publish/subscribe channels.
Atomic operations	All operations in Redis are atomic, meaning no race conditions.
Lua scripting	Supports server-side scripting for complex operations.
Replication & Clustering	Redis supports master-slave replication and automatic partitioning for scalability.

Why Storing Data in RAM are Fast

Core Reason: Physical Design

Component	Made Of	How It Works	Speed
RAM (Memory)	Tiny electronic circuits (transistors & capacitors)	Stores bits as electric charges directly accessible by the CPU	⚡ Nanoseconds (10⁻⁹ sec)
Disk (Storage)	Moving parts (HDD) or flash cells (SSD)	Data must be located, read, and transferred through several layers	🐢 Microseconds–milliseconds (10⁻⁶–10⁻³ sec)

In simple terms:

• RAM is electronic: data is stored in active circuits the CPU can access instantly.
• Disk is mechanical (in HDDs) or block-based (in SSDs), requiring extra steps to find and read data.

Different Access Path

RAM

CPU → Memory Controller → RAM chip → Data returned

• Data is fetched directly from memory chips sitting right beside the CPU.
• No moving parts, no searching, no delays.

Disk

CPU → OS → File System → Storage Controller → Disk → Locate file block → Read data → Return

• The CPU must ask the OS, which must find the file, then the disk driver must locate the block, and finally read it.
• Even SSDs, while fast, involve these multiple layers.

Architecture

Redis is designed to be lightweight, simple, and blazing fast. Its architecture is centered around a single-threaded model and an event loop.

Single Threaded Model

Redis runs on a single main thread for executing commands.

• This means one command is executed at a time.
• No context-switching overhead like in multi-threaded systems.
• Simpler design → avoids race conditions and locks.
• Extremely fast because operations are done in memory.

Even though Redis is single-threaded for command execution, it can still handle hundreds of thousands of requests per second because most operations are O(1) (constant time).

Example:

If two clients send commands:

1. Client A: SET user:1 "Masum"
2. Client B: GET user:1

Redis processes them one after another in sequence (not simultaneously). So the output is deterministic and no data corruption occurs.

Event Loop

Redis uses an event-driven architecture based on an event loop.

• The event loop listens for incoming connections, commands, and responses.
• Uses epoll (Linux), kqueue (BSD/Mac), or select/poll (older systems) for efficient I/O multiplexing.
• Allows Redis to manage thousands of client connections concurrently without spawning multiple threads.

Redis doesn’t block while waiting for I/O. Instead, it registers events and processes them asynchronously.

How it works step by step

1. Clients send requests (commands).
2. The event loop listens and queues requests.
3. Redis processes commands sequentially (single-threaded execution).
4. Responses are sent back to clients.
5. Event loop continues without blocking.

Why Single-Threaded but Still Fast?

• Data stored in RAM → super fast access.
• Operations are simple (like SET, GET, INCR) → most are O(1).
• No overhead of locks or thread synchronization.
• Network I/O handled efficiently with non-blocking event loop.

That’s why Redis can easily achieve >100,000 operations per second on normal hardware.

Example Workflow

1. Client Request 1: SET session:101 "Masum" EX 60. Stores a session with 60-second expiry.

2. Client Request 2 (immediately after): GET session:101. Returns "Masum" instantly.

3. Event Loop Handling:

   • Event loop receives both requests.
   • Adds them to the queue.
   • Processes SET first, then GET.
   • Since it’s sequential, there’s no risk that GET runs before SET.

This guarantees consistency and simplicity, even with thousands of concurrent clients.