Why Redis?

Part 1: What Is Redis?

The Desk Analogy

Imagine you’re a librarian in a huge library.

Your filing system is perfect, but documents are stored in the archive—it takes 5 minutes to retrieve anything. To speed things up, you keep frequently requested documents on your desk. Someone asks for “User Profile Document #42”? Boom. Instant access from your desk.

That’s Redis.

Redis stands for Remote Dictionary Server. It’s an in-memory data structure store that keeps your most frequently accessed data in RAM instead of on disk.

1
Regular Database: Request → Query disk → Parse results → Return (milliseconds)
2
Redis: Request → Check RAM → Return (microseconds)

The difference isn’t just faster. It’s orders of magnitude faster.

The Three Truths About Redis

1. In-Memory: Data lives in RAM, not on disk
2. Single-Threaded: All commands execute sequentially on one thread
3. Fast: Every operation is atomic and blazingly quick

But here’s where beginners get confused: Redis isn’t just a cache. It’s more like a specialized database designed for specific use cases. Yes, you can use it to cache data. But you can also use it as:

• A session store (remember user login info)
• A real-time leaderboard (gaming, sports)
• A message broker (app communication)
• A rate limiter (API throttling)
• A real-time analytics engine
• A pub/sub system (real-time notifications)

All because of its speed and rich data structures.

Part 2: Why Is Redis So Incredibly Fast?

You can’t understand Redis without understanding why it’s fast. There are three pillars.

Pillar 1: In-Memory Storage (The Biggest Win)

This is the main reason Redis is so fast.

Memory Access: ~1-100 nanoseconds (billionths of a second)

SSD Access: ~100 microseconds (millionths of a second)

HDD Access: ~5-20 milliseconds (thousandths of a second)

Accessing data from RAM is 1,000-10,000x faster than from disk.

1
Time for 1 million operations:
2
From disk:  1,000,000 × 10 μs = 10 seconds
3
From RAM:   1,000,000 × 0.1 μs = 0.1 seconds

That’s the speed difference. By keeping everything in RAM, Redis eliminates the biggest bottleneck in traditional databases: disk I/O.

When you request data from PostgreSQL or MySQL:

1. Check buffer pool (in-memory cache)
2. If not there, go to disk
3. Read from disk (slow)
4. Load into buffer pool
5. Return data

Redis skips steps 2-4 entirely. The data is already in memory.

Pillar 2: Single-Threaded Command Execution

This sounds like a limitation. “How can a single thread be fast with thousands of clients?”

The answer is clever: Redis is single-threaded, but clients are handled concurrently.

Here’s why single-threading is actually an advantage:

1. No locks needed – If only one thread executes commands, there are no race conditions. No locks. No contention.
2. No context switching – The CPU doesn’t waste cycles switching between threads
3. No cache invalidation – Each thread has its own cache; single thread uses one cache
4. Predictable behavior – Commands execute in order; no unpredictable timing issues

Compare this to multi-threaded databases where you need to acquire locks before reading/writing—all that overhead goes away.

1
Single-threaded (Redis):
2
[Command 1] → [Command 2] → [Command 3]
3
No synchronization needed, blazing fast
4

5
Multi-threaded (Traditional DB):
6
Thread 1: [Command 1] → (acquire lock) → (do work) → (release lock)
7
Thread 2: [Command 2] → (waiting for lock...) → (acquire) → (do work) → (release)
8
Thread 3: [Command 3] → (waiting for lock...) → (waiting...) → (acquire) → (do work)
9
More overhead, more latency

Pillar 3: Highly Optimized C Code and Data Structures

Redis is written in ANSI C—a language known for performance. Beyond that, every data structure is custom-built and optimized.

Examples:

• Simple Dynamic Strings (SDS): Instead of standard C strings, Redis uses a struct that stores length metadata. This makes getting the string length O(1) instead of O(n).
• Ziplists: For small hashes and sets, Redis stores data in a compact, contiguous block of memory. No pointers, no fragmentation, just raw efficiency.
• Intsets: Integer sets are stored as sorted arrays without any overhead.

The result? Less memory, less CPU usage, faster operations.

Part 3: The Architecture: How Redis Handles Thousands of Clients

Here’s the question every engineer asks: “You said Redis is single-threaded. How does it handle thousands of concurrent client connections?”

The Kitchen Analogy

Imagine you’re a chef. You can only cook one dish at a time (single-threaded). But you have sous chefs (the operating system) watching multiple burners.

1
You (Redis main thread):     Chopping veggies
2
Sous Chef 1 (OS):            "Chef, burner #3 is ready!"
3
You:                         Drop your knife, plate burner #3
4
You:                         Go back to chopping veggies
5
Sous Chef 2 (OS):            "Chef, burner #1 is ready!"
6
You:                         Plate burner #1, go back to chopping

In reality, here’s what happens:

1. Client connects → OS registers their socket
2. Client sends command → OS notifies Redis via epoll (Linux) or kqueue (macOS)
3. Redis reads command → Executes it on the main thread
4. Redis sends response → OS handles the actual network transmission
5. Redis goes back to listening → Waits for the next event

This is called event-driven I/O multiplexing. The operating system efficiently watches thousands of sockets and notifies Redis which ones are ready. Redis doesn’t sit around waiting—it’s always doing something.

The Process Flow

1
┌──────────────────────────────────────────────────────┐
2
│           Redis Event Loop (Single Thread)           │
3
└──────────────────────────────────────────────────────┘
4
                        │
5
        ┌───────────────┼───────────────┐
6
        │               │               │
7
        ▼               ▼               ▼
8
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
9
│ Client 1     │ │ Client 2     │ │ Client 3     │
10
│ Socket       │ │ Socket       │ │ Socket       │
11
└──────────────┘ └──────────────┘ └──────────────┘
12
        │               │               │
13
        └───────────────┼───────────────┘
14
                        │
15
                        ▼
16
        ┌──────────────────────────────┐
17
        │  OS (epoll/kqueue/IOCP)      │
18
        │  "These sockets are ready"   │
19
        └──────────────────────────────┘

Result: One thread efficiently handles thousands of connections by never waiting. The OS handles the I/O; Redis just executes commands.

Part 4: Data Structures (Why Redis Is More Than a Cache)

Redis has rich data types. This is what makes it versatile.

String

The simplest type. A key-value pair where the value is text or binary data.

1
SET username "alice"
2
GET username  # Returns "alice"

Use case: Storing user preferences, simple caching, counters.

Hash

A mapping of fields to values. Perfect for complex data.

1
HSET user:1 name "Alice" age 25 city "NYC"
2
HGET user:1 name  # Returns "Alice"

Use case: Storing user profiles, product details, any object with multiple properties.

List

An ordered sequence. Perfect for queues and timelines.

1
LPUSH notifications "New comment on post"
2
LPUSH notifications "Friend request from Bob"
3
LRANGE notifications 0 -1  # Get all notifications

Use case: Message queues, chat history, activity feeds, job queues.

Set

An unordered collection of unique values.

1
SADD tags:post123 "javascript" "redis" "database"
2
SMEMBERS tags:post123  # Get all tags
3
SISMEMBER tags:post123 "redis"  # Is "redis" a tag? (true)

Use case: Storing tags, followers, unique visitors, memberships.

Sorted Set

A set where each element has a score. Automatically sorted by score.

1
ZADD leaderboard 100 "alice" 85 "bob" 95 "charlie"
2
ZREVRANGE leaderboard 0 2  # Top 3 players
3
# Returns: ["alice", "charlie", "bob"]

Use case: Leaderboards, real-time rankings, rate limiting by time.

Part 5: Redis as a Cache (The Most Common Use Case)

Let’s say you’re building a user profile page.

Without Redis:

1
User requests profile
2
↓
3
Query PostgreSQL ("SELECT * FROM users WHERE id = 123")
4
↓
5
Database searches through millions of rows
6
↓
7
Returns data
8
↓
9
Render profile (200-500ms)

Every request hits the database. If 1000 users view the same profile, the database executes the same query 1000 times.

With Redis:

1
User requests profile
2
↓
3
Check Redis: "Does user:123 exist?"
4
↓
5
YES: Return immediately (1-5ms) ← Cache HIT
6
OR
7
NO: Query PostgreSQL, cache result in Redis, return (200-500ms) ← Cache MISS
8
↓
9
Next user requests same profile
10
↓
11
Check Redis: "Does user:123 exist?"
12
↓
13
YES: Return immediately (1-5ms)

The second request is 100x faster.

How to Implement Caching

1
// Pseudo-code (works in any language)
2
function getUserProfile(userId) {
3
  // Check cache
4
  cached = redis.get(`user:${userId}`);
5
  if (cached) {
6
    return cached; // Cache hit
7
  }
8

9
  // Cache miss: go to database
10
  user = database.query(`SELECT * FROM users WHERE id = ?`, userId);
11

12
  // Store in cache with 15-minute expiration (TTL)
13
  redis.setex(`user:${userId}`, 900, user);
14

15
  return user;
16
}

Cache Invalidation

The famous saying goes: “There are only two hard things in Computer Science: cache invalidation and naming things.”

When data changes, you must invalidate the cache:

1
function updateUserProfile(userId, newData) {
2
  // Update database
3
  database.update(userId, newData);
4

5
  // Invalidate cache
6
  redis.delete(`user:${userId}`);
7
}

The next request will cache miss, fetch fresh data, and cache it again.

Part 6: Redis as a Database (Real-Time Leaderboards)

Not every use case needs a traditional database. Real-time leaderboards are perfect for Redis.

The Leaderboard Problem

Imagine a gaming application with millions of players. You need to:

• Update scores instantly as players play
• Show top 10 players instantly
• Allow players to see their rank instantly

A traditional database would be too slow.

The Redis Solution

1
// Player scores a point
2
ZADD leaderboard 100 "player:123"
3

4
// Another player
5
ZADD leaderboard 150 "player:456"
6

7
// Get top 10 players (ordered by score, descending)
8
ZREVRANGE leaderboard 0 9 WITHSCORES
9
# Returns: ["player:456", "150", "player:123", "100", ...]
10

11
// Get a specific player's rank
12
ZREVRANK leaderboard "player:123"
13
# Returns: 2 (they're 2nd)

Performance:

• Writing a score: ~1ms
• Getting top 10: ~1ms
• Getting a rank: ~1ms

With SQL, you’d need to sort millions of rows every query. Redis keeps it sorted automatically.

Why This Works

Sorted sets in Redis are implemented using skip lists, a probabilistic data structure. They maintain order while allowing fast inserts and range queries. It’s like having a pre-sorted leaderboard that updates in real-time.

Part 7: Persistence (What Happens If Redis Crashes?)

Redis stores data in RAM. If the server crashes, all data is gone.

“That’s a problem,” you might think.

Redis solves this with persistence mechanisms. Two options:

Option 1: RDB (Snapshots)

Redis periodically takes a snapshot of the entire dataset and saves it to disk.

1
Time 0:   RDB snapshot saved
2
Time 5m:  (Redis running, data in RAM)
3
Time 10m: RDB snapshot saved
4
Time 15m: Crash! Server goes down
5
Time 15m+5s: Server restarts, loads last RDB snapshot

Pros:

• Fast to save (happens in background)
• Fast to restore (one large binary file)
• Perfect for backups

Cons:

• Up to 10 minutes of data loss (depending on snapshot frequency)
• RDB snapshots can be large

Option 2: AOF (Append-Only File)

Redis logs every write command. If it crashes, replay the log to recover.

1
Time 0:   SET user:1 alice   → Written to log
2
Time 1:   SET user:2 bob     → Written to log
3
Time 2:   ZADD leaderboard 100 alice  → Written to log
4
Time 3:   Crash!
5
Time 3+:  Server restarts, replays log
6
          "SET user:1 alice"
7
          "SET user:2 bob"
8
          "ZADD leaderboard 100 alice"

Pros:

• Minimal data loss (only last 1 second)
• Human-readable log (you can inspect it)
• More durable

Cons:

• AOF files grow larger over time
• Slightly slower write performance

The Recommendation

Use both:

• AOF for durability (continuous logging)
• RDB for backups (periodic snapshots)

Configure AOF to sync every 1 second (good balance between safety and performance).

1
appendfsync everysec  # Best practice

Part 8: Real-World Use Cases

Use Case 1: Session Storage

Store user login information for fast retrieval.

1
SET session:abc123def456 '{"userId": 789, "role": "admin"}'
2
EXPIRE session:abc123def456 3600  # Expire in 1 hour
3

4
# When user returns
5
GET session:abc123def456  # Instant retrieval

Why Redis: Sessions are accessed on every request. Disk-based sessions are too slow.

Use Case 2: Rate Limiting

Prevent abuse by limiting requests per user.

1
INCR requests:user:123  # Increment counter
2
EXPIRE requests:user:123 60  # Reset every minute
3

4
# If counter > 100, reject request

Why Redis: You need atomic operations and precise timing. Redis handles this in microseconds.

Use Case 3: Real-Time Chat

Store messages and deliver them to online users.

1
LPUSH chat:room:general "User A: Hello"
2
LPUSH chat:room:general "User B: Hi there"
3
LRANGE chat:room:general 0 49  # Get last 50 messages
4

5
PUBLISH chat:room:general "User A: Hello"  # Broadcast to all subscribers

Why Redis: You need fast message storage and pub/sub for real-time delivery.

Use Case 4: Real-Time Analytics

Track metrics in real-time.

1
INCR page:views:home  # Homepage view count
2
ZADD user:activity 1703664120 "alice_login"  # When user logs in

Why Redis: You need microsecond-level performance for thousands of concurrent events.

Part 9: The Trade-Offs (What You Need to Know)

Redis is amazing, but it’s not perfect.

Limited by RAM

Your dataset can’t exceed available memory. A 128GB Redis instance stores max 128GB of data. A SQL database can store terabytes on disk.

Solution: Use Redis for hot data (recently accessed). Archive old data to disk.

Single-Threaded

CPU-intensive operations block other clients.

1
// Bad: Blocking operation
2
EVAL (for loop 1 million times) ...
3

4
// Good: Quick operations
5
ZADD leaderboard 100 player:123

Solution: Keep operations fast. Move heavy computation elsewhere.

Data Loss Risk

Without persistence, a crash loses all data.

Solution: Enable persistence (RDB or AOF).

Complex Queries

Redis isn’t great for complex filtering.

1
// Redis struggles with this
2
"Find all users aged 25-30 who logged in today"
3

4
// SQL excels at this
5
SELECT * FROM users WHERE age BETWEEN 25 AND 30 AND last_login > TODAY

Solution: Use Redis for simple access patterns. SQL for complex queries.

Scaling

A single Redis instance has limits. Scaling horizontally (multiple instances) requires cluster mode, which adds complexity.

SQL handles replication and sharding more naturally.

Conclusion: The Big Picture

Redis is simple: an in-memory data structure store optimized for speed.

It’s single-threaded but handles thousands of concurrent clients through efficient I/O multiplexing. It’s fast because it stores everything in RAM and uses optimized data structures.

But it’s not magic. It trades durability for speed, storage capacity for performance. It’s perfect for specific problems:

• Caching: Replace slow database queries
• Sessions: Store user login info
• Leaderboards: Real-time rankings
• Rate limiting: Prevent abuse
• Real-time features: Chat, notifications, analytics
• Message brokers: Queue jobs, pub/sub messaging

It’s not perfect for everything. Use Redis where speed matters. Use SQL where durability and complex queries matter.

Next Steps

• Practice: Spin up Redis locally and experiment with different data types
• Read: Check out the official Redis documentation
• Deep dive: I will be writing more blogs on redis in the coming days, you can check them out for a deeper understanding of certain concepts
• Production: When you use Redis in a real application, measure its impact with monitoring tools like Redis Insight or Datadog

Redis isn’t just a cache. It’s a powerful, elegant tool. Once you master it, you’ll understand why it’s used by companies like Netflix, Twitter, and GitHub.

Happy caching!