What Is Redis & Why

Redis is everywhere, and usually described in one word: “cache.” That’s true but thin — it misses why Redis is fast and what makes it uniquely useful. The honest one-line definition is “an in-memory data-structure store,” and unpacking those three ideas — in-memory, data-structure, store — explains everything the rest of the course builds on. Let’s get the model right first, with real numbers.

Three design choices

1. In-memory. Redis keeps the entire dataset in RAM, not on disk. That’s the root of its speed: RAM access is measured in nanoseconds and disk (even SSD) in microseconds-to-milliseconds, so operations complete in well under a millisecond. The trade-off is that your data must fit in memory, and memory is volatile — which is why persistence (Lesson 7) exists to survive restarts. But the core idea is simple: Redis is fast because it never waits for disk on the hot path.

2. Data structures, not blobs. Unlike a plain key-value cache that stores opaque bytes, Redis stores rich data structures — strings, lists, hashes, sets, sorted sets, streams — and gives you server-side operations on them: INCR a counter, LPUSH onto a list, ZADD to a sorted set, SINTER to intersect sets. This is the feature that makes Redis far more than a cache: you push computation to where the data lives, so a leaderboard update is one ZADD, not “read the whole list, sort in the app, write it back.” The data structures (Lesson 2) are the heart of Redis’s power.

3. Single-threaded core. Here’s the one that surprises people: Redis executes your commands on a single thread, one at a time, in order. That sounds like a bottleneck, but it’s a deliberate strength:

• Every command is atomic. Because only one command runs at a time, there are no locks, no race conditions, no partial updates to reason about. INCR is atomic for free; a check-then-set is a single command, not a race. This makes Redis a superb coordinator (Lesson 10).
• The code stays simple and fast. No lock contention, no context-switching overhead, cache-friendly execution. The single thread, working in RAM on O(1) structures, is astonishingly fast.

(Networking and some background work are multi-threaded in modern Redis, and you scale further with replicas and Cluster — Lessons 8–9 — but the command execution is single-threaded, and that’s the model to hold.)

Measured: how fast is “fast”?

Rather than hand-wave, I benchmarked a stock Redis 7 instance with no tuning:

• SET: 94,473 ops/sec, p50 latency ~0.26 ms.
• GET: 90,416 ops/sec, p50 ~0.27 ms.

So a single Redis instance handles roughly 100,000 operations per second at sub-millisecond latency, out of the box. That throughput comes from the three choices above: the data is in RAM (no disk wait), the operations are O(1) (simple structures), and the single thread runs them back-to-back with no locking overhead. And this is before pipelining (Lesson 5), which multiplies it 16–25×. For the vast majority of workloads, one Redis instance is more than enough — and when it isn’t, you scale with replicas (reads) and Cluster (sharding).

What Redis is for

Those properties point to three jobs Redis does better than almost anything:

• A cache — the classic use. Put Redis in front of a slow database or API; serve hot reads from RAM in microseconds, falling back to the source on a miss (Lesson 4). This is how you take load off a database and cut latency dramatically.
• A fast data store for ephemeral or hot state — sessions, counters, rate limits, leaderboards, feature flags, real-time analytics. Data that’s accessed constantly and can live in RAM (with persistence if it’s the source of truth).
• A lightweight message broker — pub/sub for live fan-out, and streams for durable queues (Lesson 6).

And crucially, what Redis is not: a replacement for your primary database. It’s the fast layer beside your durable store, not instead of it. Your system of record — the data you can never lose, that needs complex queries and transactions across large datasets — belongs in a database (the Database Internals course is about that side). Redis is the speed layer: hot data, fast operations, simple access patterns. Use each for what it’s good at.

With the model in place, the next lesson goes to the heart of Redis’s power: the data structures themselves.

Pitfalls to Avoid

1. Treating Redis as “just a key-value cache.” You miss its real power — the data structures and server-side operations. A leaderboard, a rate limiter, a unique-count are a few commands in Redis; done naively elsewhere they’re whole subsystems.
2. Forgetting data lives in RAM. Your dataset must fit in memory, and memory is the hard limit (Lesson 3). Treating Redis as infinite storage leads to the #1 incident: running out of RAM.
3. Assuming single-threaded means slow. One thread in RAM on O(1) structures does ~100k ops/sec. But it also means one slow command blocks everything (Lesson 12) — keep commands O(1)/O(log n).
4. Using Redis as your primary database. It’s the fast layer, not the system of record. Storing data you can’t lose or must query richly, with no durable backing, is a data-loss and capability trap.
5. Ignoring persistence when Redis is a store. If Redis holds the only copy of something (not just a cache), a restart loses it unless you’ve configured persistence (Lesson 7). Decide: cache or store?

Quick Recap

• Redis is an in-memory data-structure store: data in RAM (microsecond access), stored as rich data structures (not blobs) with server-side operations, executed on a single thread.
• Single-threaded is a feature: every command is atomic (no locks/races), and the code stays simple and fast.
• Measured: one stock instance does SET 94,473 / GET 90,416 ops/sec at sub-ms p50 — ~100k ops/sec, before pipelining multiplies it (Lesson 5).
• Three jobs it’s best at: cache, fast store for hot/ephemeral state, lightweight message broker. It is not your primary database — it’s the fast layer beside it.

Next lesson: the heart of Redis’s power — the core data structures and when to use each.