Redis — The In-Memory Data-Structure Store, End to End
A practical, measurement-grounded course on Redis for backend engineers: what Redis is (an in-memory, single-threaded data-structure store), the core data structures (strings, lists, hashes, sets, sorted sets, streams) and when to use each, keys/expiry/memory and eviction, caching patterns and their traps, pipelining and transactions, pub/sub and streams, persistence (RDB vs AOF), replication and Sentinel HA, Redis Cluster and sharding, distributed locks and coordination, advanced patterns (leaderboards, rate limiting, HyperLogLog, bitmaps, geo), and operating Redis in production. Grounded in REAL redis-benchmark numbers: ~100k ops/sec per instance, pipelining 16–25x, sub-millisecond latency.
Redis is one of the most-used pieces of infrastructure in the world — the fast layer in front of slow databases, the home for sessions and counters and leaderboards, a lightweight message broker, and a distributed coordinator. But it’s often used as a black-box “cache” with no understanding of why it’s fast, what its data structures unlock, or how it behaves under memory pressure and failover. This course builds Redis up properly — from the in-memory, single-threaded core, through the data structures and the patterns they enable, to persistence, replication, clustering and production operation — with the important claims grounded in real benchmark numbers I ran, not adjectives.
We start by getting the core model right: Redis keeps data in RAM as real data structures, and runs commands on a single thread — which sounds limiting but makes every command atomic and delivers ~100,000 operations a second per instance. From there we go through the data structures (strings, lists, hashes, sets, sorted sets, streams) and what each is for, then keys, expiry and memory (TTLs, maxmemory, eviction — because running out of RAM is the #1 Redis incident), and the caching patterns everyone uses and the three classic bugs that come with them (stale data, stampedes, caching everything).
Then the performance and messaging features: pipelining and transactions (the biggest throughput lever, measured at 16–25×), pub/sub and streams (fire-and-forget vs durable), persistence (RDB vs AOF, and the “it’s just a cache” myth), replication and high availability (replicas and Sentinel failover), and Redis Cluster (hash slots and sharding). We finish with distributed locks and coordination (SETNX, Redlock, rate limiting, Lua scripts), advanced patterns (leaderboards, rate limiting, HyperLogLog, bitmaps, geo), and operating Redis in production — the big-key and slow-command traps that make a fast Redis go slow.
It’s written in plain Indian English with a working engineer in mind, and it’s grounded in real measurements from redis-benchmark on a running Redis 7: SET at 94,473 ops/sec and GET at 90,416 ops/sec at sub-millisecond p50; data-structure ops (INCR, ZADD, RPUSH, SADD, HSET) all around ~100k ops/sec; and pipelining lifting GET throughput from ~93k to 1.5M ops/sec at P=16 (16×) and 2.37M at P=64 (25×). Every lesson ends with pitfalls and a quick recap.
What This Course Covers
| # | Lesson | What you will learn |
|---|---|---|
| 1 | What Is Redis & Why | In-memory, single-threaded, data-structure store (measured) |
| 2 | The Data Structures | Strings, lists, hashes, sets, sorted sets, streams — and when to use each |
| 3 | Keys, Expiry & Memory | TTLs, maxmemory, eviction policies, key design |
| 4 | Caching Patterns | Cache-aside, write-through; stale data, stampedes, invalidation |
| 5 | Pipelining & Transactions | Pipelining (measured 16–25×), MULTI/EXEC, WATCH, Lua |
| 6 | Pub/Sub & Streams | Fire-and-forget pub/sub vs durable streams; vs Kafka |
| 7 | Persistence & Durability | RDB snapshots vs AOF; is it a cache or a store? |
| 8 | Replication & HA | Replicas, Sentinel, automatic failover |
| 9 | Redis Cluster & Scaling | Hash slots, sharding, the same-slot constraint |
| 10 | Distributed Locks & Coordination | SETNX, Redlock, rate limiting, atomic ops, Lua |
| 11 | Advanced Patterns | Leaderboards, rate limiting, HyperLogLog, bitmaps, geo |
| 12 | Operating Redis & Pitfalls | Big keys, slow commands, monitoring, when NOT to use it |
Who Is This For?
- Backend engineers who use Redis as a cache but want to understand it properly
- Anyone building sessions, counters, leaderboards, rate limiters or queues on Redis
- Engineers facing Redis memory, persistence, replication or clustering decisions
- Developers who want the data structures and patterns Redis makes trivial — and the traps to avoid
This course pairs naturally with the other backend courses on the site — Database Internals for Backend Engineers (the durable store Redis sits in front of), Apache Kafka (the heavy-duty log, vs Redis Streams), Distributed Systems in Practice (the replication and failover ideas under Redis HA), and Go for Backend Engineers (a great language for building Redis-backed services).
How to Use It
Read it in order the first time — it builds from the in-memory core through data structures, memory, caching, performance, messaging, persistence, HA, clustering, coordination and operation. After that, keep it as a reference: when you’re choosing a data structure (Lesson 2), setting TTLs and eviction (Lesson 3), fixing a cache bug (Lesson 4), speeding things up (Lesson 5), deciding persistence (Lesson 7), or scaling out (Lessons 8–9), come back to that lesson. The measured numbers are there so you can reason about Redis with real figures, and the pitfalls sections are where the hard-won operational lessons live.
Let’s start with what Redis actually is, and why its in-memory, single-threaded design makes it so fast.