What Redis Is and When to Use It

Redis gets reached for reflexively, "just add Redis," as if it were a single fix for slowness. It's genuinely one of the most useful tools in a backend engineer's kit, but using it well starts with understanding what it actually is: an in-memory data structure store, not just a cache. Once you see it as a fast, versatile store of real data structures, the range of problems it solves cleanly (caching, rate limiting, queues, sessions, leaderboards, locks) stops looking like a grab bag and starts looking like one idea applied many ways.

This is the opening article of the Redis Masterclass, and it builds on the PostgreSQL series: Redis usually sits alongside a primary database like Postgres, not instead of it.

In-memory is the whole point

Redis keeps its data in RAM. That single fact explains most of its character. Reading from memory is orders of magnitude faster than reading from disk, so Redis operations typically complete in well under a millisecond, and a single instance handles a very high request rate. That speed is why it's the default choice for anything on the hot path, where a database round trip would be too slow.

The tradeoff is that RAM is smaller and more expensive than disk, and volatile. Redis addresses durability with persistence options we'll cover later, but the mental model to start with is: Redis is fast because it's in memory, and you use it for data that benefits from being fast to access, not as the permanent home for everything.

It's a data structure store, not a key-value blob

The common misconception is that Redis is a simple key-value store, strings in and strings out. It's much more. Redis stores real data structures as values, each with its own commands:

• Strings for simple values, counters, and cached blobs.
• Hashes for objects with fields, like a user record.
• Lists for ordered sequences and simple queues.
• Sets for unique collections and membership checks.
• Sorted sets for ranked data like leaderboards and priority queues.
• Plus streams, bitmaps, HyperLogLog, geospatial indexes, and probabilistic structures.

This is what makes Redis versatile. A leaderboard is a sorted set. A rate limiter is a counter with expiry. A job queue is a list or a stream. Each of these is a data structure Redis already implements with atomic operations, so you get the behavior for free instead of building it. The rest of this series is largely a tour of these structures and the patterns they enable.

What Redis is great at

The strong use cases share a shape: fast access to data that's either transient or a cheap-to-rebuild copy of something authoritative.

• Caching: storing the result of an expensive query or computation so you don't redo it. The most common use, and the subject of a whole module here.
• Session storage: user sessions that need fast reads on every request and don't belong in your primary database.
• Rate limiting: counting requests per user per window, which is a counter-with-expiry, exactly what Redis does well.
• Queues and job processing: lists and streams back many task-queue systems.
• Real-time features: leaderboards, counters, pub/sub messaging, presence, all things that want sub-millisecond updates.
• Distributed coordination: locks and semaphores across multiple application servers.

What Redis is not for

Knowing the boundaries matters as much as the uses. Redis is the wrong tool when:

• You need it as your primary database for critical data. Redis has persistence, but its model favors speed over the durability guarantees of a relational database. Your source of truth for orders, payments, and user accounts should be a database like Postgres, with Redis as a fast layer in front.
• The data doesn't fit in memory. Redis holds everything in RAM, so a dataset far larger than your memory budget isn't a fit without careful design, and a disk-based database is often the better home.
• You need complex queries, joins, or ad-hoc reporting. Redis has no SQL, no joins, no query planner. It's fast at the access patterns its data structures support and not built for arbitrary querying.

The recurring principle: Redis complements a primary database, it doesn't replace one. Postgres owns the durable, queryable source of truth; Redis makes the hot paths fast.

The mental model to carry forward

Think of Redis as a box of fast, atomic data structures living in memory, sitting next to your real database. When a problem maps onto one of those structures (a counter, a ranked set, a queue, a cached value) Redis solves it cleanly and quickly. When a problem needs durability, complex queries, or more data than fits in RAM, that's the database's job. Most well-built systems use both, each for what it's good at.

With that framing, the rest of this series makes sense as a progression: first the data structures themselves, then the caching patterns that are Redis's most common job, then the infrastructure uses (queues, locks, rate limiting), and finally running Redis reliably in production.

Next, we get concrete with the core data structures, starting with an overview of strings, hashes, lists, sets, and sorted sets, and which real problems each one is shaped for.