System Design
Top 10 Redis Use Cases
Redis is the Swiss Army knife of fast data. Beyond caching, it powers leaderboards, rate limiters, queues, real-time messaging, and more. Here are the ten use cases that show up most in real systems - and which Redis feature powers each.
Most people first meet Redis as a cache, and assume that's mostly what it does. But Redis is far more versatile than a cache - it's a fast in-memory data store with a rich set of data structures, and that combination makes it the go-to tool for a surprising range of jobs. Once you know what Redis can do, you start seeing places to use it everywhere a system needs speed, from throttling abusive clients to ranking players to broadcasting live updates.
This guide covers the ten Redis use cases that show up most often in real systems, and - importantly - which Redis feature or data structure powers each. Understanding the mapping from use case to feature is what lets you reach for Redis correctly. (For why Redis is so fast under the hood, see the companion piece on Redis's speed.)
graph TD
R[Redis] --> STR[Strings / counters]
R --> HASH[Hashes]
R --> LIST[Lists]
R --> SET[Sets]
R --> ZSET[Sorted sets]
R --> PS[Pub/Sub & Streams]
STR --> U1[Caching, rate limiting, counters]
HASH --> U2[Session storage, objects]
LIST --> U3[Queues, task queues]
SET --> U4[Deduplication, tags]
ZSET --> U5[Leaderboards, geospatial]
PS --> U6[Real-time messaging, events]
This diagram maps Redis data structures to the use cases they power. Strings and counters power caching, rate limiting, and counters. Hashes power session storage and objects. Lists power queues and task queues. Sets power deduplication and tags. Sorted sets power leaderboards and geospatial queries. Pub/Sub and Streams power real-time messaging and event processing. Redis's versatility comes from this rich set of purpose-built data structures.
1. Caching
The classic and most common use. Redis sits in front of a slower database, storing frequently-accessed data in memory so reads are served at sub-millisecond speed instead of hitting the database. The typical pattern is cache-aside: the application checks Redis first, and on a miss, reads from the database and stores the result in Redis for next time.
Why Redis fits: in-memory speed is exactly what a cache needs, and losing the cache on a restart is usually fine (it refills from the source). Caching can dramatically reduce database load and improve response times - often the single highest-impact performance optimization a system makes.
2. Session storage
Web applications need somewhere to store user session data (who's logged in, their cart, their preferences) that's fast to read and write on every request. Redis is a natural fit: store each session by a session ID key, read and write it at memory speed.
Why Redis fits: sessions need fast access on every request, and Redis delivers it. Storing sessions in Redis (rather than in each application server's memory) also means any server can handle any user's request - essential for a stateless, horizontally-scalable application tier. (See the stateful vs stateless guide.)
3. Rate limiting
Controlling how many requests a user or client can make in a time window requires fast, atomic counting. Redis handles this with atomic increment operations and key expiration: increment a per-user counter, set it to expire after the window, and reject requests when the count exceeds the limit.
Why Redis fits: Redis's operations are atomic (its single-threaded model guarantees it), so counters increment correctly even under heavy concurrent load, and built-in key expiration handles the time windows automatically. This makes Redis a standard choice for rate limiting. (See the rate limiting guide.)
4. Leaderboards and rankings
Showing the top players, most-active users, or highest scores - in real time, with the ability to query ranks - is awkward in a traditional database but native in Redis, thanks to its sorted set data structure. A sorted set keeps members ordered by a score, so you can fetch the top N, a member's rank, or a range of ranks instantly.
Why Redis fits: the sorted set is purpose-built for ranked data, giving fast ranked queries that would require expensive sorting in a relational database. Real-time leaderboards are one of Redis's signature use cases.
5. Counting and real-time analytics
Tracking counts at high speed - page views, likes, active users, clicks - benefits from Redis's fast atomic counters. Increment a counter on each event, read it instantly. Redis also offers specialized structures for approximate counting of unique items at scale (counting unique visitors without storing every one).
Why Redis fits: atomic, in-memory increments handle high-frequency counting that would create heavy write load on a traditional database, and the results are available in real time. For live dashboards and metrics, Redis provides the speed.
6. Queues and task queues
Redis lists work as queues - push tasks onto one end, pop them off the other - making Redis a lightweight job/task queue for background processing. A web request can enqueue a task in Redis, and worker processes pull tasks off the queue to process asynchronously.
Why Redis fits: list operations are fast and atomic, and Redis's speed makes it a low-latency queue. For many systems, a Redis-backed queue is a simple, effective way to handle background jobs without a heavier dedicated message broker. (See the message queues guide.)
7. Pub/Sub and real-time messaging
Redis has a built-in publish/subscribe feature: publishers send messages to channels, and subscribers listening on those channels receive them in real time. This powers real-time features like live notifications, chat, and broadcasting updates to connected clients.
Why Redis fits: Redis Pub/Sub is fast and simple, making it a quick way to add real-time messaging to a system - for example, broadcasting an event to all the application servers holding WebSocket connections, so they can push updates to clients. (See the pub/sub and WebSockets guides.)
8. Distributed locks
When multiple processes or servers need to coordinate access to a shared resource - ensuring only one does something at a time - Redis can act as a distributed lock. A process acquires the lock by setting a key (atomically, only if it doesn't exist), holds it while working, and releases it by deleting the key, with an expiration as a safety net.
Why Redis fits: Redis's atomic operations and key expiration make it possible to implement a lock that coordinates across many machines, fast. Distributed locking has subtleties to get right, but Redis is a common foundation for it.
9. Geospatial queries
Redis can store location data and answer "what's near this point" queries through its geospatial features (built on sorted sets). Add locations with coordinates, then query for members within a radius of a point.
Why Redis fits: for fast "nearby" lookups - drivers near a rider, stores near a user - Redis offers geospatial queries at memory speed, useful as a fast layer for location features. (See the geohashing guide for the technique behind spatial indexing.)
10. Streams and event processing
Redis Streams is a data structure for handling a continuous stream of events - an append-only log that multiple consumers can read from, with consumer groups for distributing work. It enables event-driven processing and acts as a lightweight event streaming system.
Why Redis fits: Streams give Redis durable, replayable event handling with consumer groups, suitable for event-driven architectures that don't need a full heavyweight streaming platform. It extends Redis from simple messaging toward stream processing.
Caching patterns worth knowing
Since caching is the most common use, it's worth understanding the patterns for how a cache stays in sync with the underlying data - because a cache that serves stale or wrong data causes subtle bugs.
- Cache-aside (lazy loading). The most common pattern: the application checks the cache first; on a miss, it reads from the database, stores the result in the cache, and returns it. The cache fills on demand with the data actually being requested. Simple and effective; the trade-off is that the first request for any item is a miss (slower), and stale data can linger until it expires or is invalidated.
- Write-through. On a write, the application updates the cache and the database together, so the cache always has fresh data. Reads are always fast and current, at the cost of writing to two places on every write.
- Write-behind (write-back). Writes go to the cache first and are flushed to the database asynchronously. Fast writes, but more complex and riskier (data could be lost if the cache fails before flushing).
Two essential cache mechanics accompany these:
- Expiration (TTL). You set a time-to-live on cached entries so they expire automatically, bounding how stale data can get and freeing memory. Redis's built-in key expiration handles this.
- Eviction. Because memory is finite, when the cache fills, Redis evicts entries by a policy (commonly least-recently-used, evicting entries not accessed in the longest time) to make room. The eviction policy matters for cache effectiveness.
Understanding these turns "add a cache" into "add a cache with the right consistency pattern and eviction policy" - the difference between a cache that helps and one that serves subtle bugs.
What Redis is NOT for
Knowing where not to use Redis is as important as knowing where to. Redis is not:
- A primary database for large or critical data that must be durable. Redis keeps data in memory (it must fit in RAM, which is limited and costly), and its durability is a tunable trade-off, not the ironclad guarantee a primary database gives. Use Redis as a fast layer in front of a durable primary store, not as the system of record for data you can't lose.
- A query engine. Redis accesses data by key and through its data structures - no rich query language, no joins, no ad-hoc querying across data. For complex queries, you need a real database.
- For data far larger than memory. Once a dataset outgrows RAM, Redis is the wrong tool; the data belongs in a disk-based store, possibly with Redis caching the hot subset.
The unifying principle: Redis excels at fast access to hot, bounded data, used alongside a primary database that handles the large, durable, queryable rest. Treat it as the fast layer, not the system of record, and it rewards you; treat it as a primary database for data that doesn't belong in memory, and it will eventually fail you. The boundary is simple - hot and bounded goes in Redis, large and durable stays in the database.
A worked example: Redis in one system
To see how these use cases combine, picture a single application using Redis for several jobs at once - which is typical. A social or gaming app might use Redis as a cache in front of its database for hot data (profiles, content), store user sessions in Redis so any server handles any request, enforce API rate limits with atomic counters, power a real-time leaderboard with a sorted set, broadcast live notifications through Pub/Sub to the servers holding client connections, and run background jobs through a Redis queue.
That's six of the ten use cases, in one application, all served by a single Redis deployment (or a few). This is the reality of Redis in production: it's not added for one thing, it's woven through a system wherever fast in-memory access to bounded data helps. Each use leans on a different Redis feature - strings for the cache and counters, sorted sets for the leaderboard, lists for the queue, Pub/Sub for notifications - which is exactly why understanding the mapping from use case to feature matters. A team that knows Redis well reaches for it reflexively across these jobs, and the cumulative effect on a system's performance and simplicity is large: one fast, familiar tool quietly carrying a half-dozen different loads.
Why Redis became the default for these jobs
It's worth asking why Redis, specifically, dominates these use cases. The answer is the combination at its core: it's in-memory (so everything is fast), it offers rich data structures (so each job has a purpose-built tool - a sorted set for ranking, a list for queuing, atomic counters for limiting), its operations are atomic (so concurrent access is correct without extra coordination), and it's simple and battle-tested (so it's easy to adopt and reliable in production). No single one of these is unique, but together they make Redis unusually well-suited to a wide span of fast-data jobs. That versatility - one familiar, fast tool that solves caching and ranking and rate limiting and messaging - is why Redis is so often the first thing engineers reach for when a system needs speed somewhere. (For the engineering behind that speed, see the companion piece on why Redis is fast.)
The use cases at a glance
| Use case | Redis feature | Powers |
|---|---|---|
| Caching | Strings (key-value) | Fast reads, reduced DB load |
| Session storage | Strings / hashes | Fast per-request session data |
| Rate limiting | Atomic counters + expiry | Request throttling |
| Leaderboards | Sorted sets | Real-time ranked queries |
| Counting / analytics | Atomic counters | High-speed real-time counts |
| Queues | Lists | Background task processing |
| Pub/Sub | Pub/Sub | Real-time messaging |
| Distributed locks | Atomic set + expiry | Cross-machine coordination |
| Geospatial | Sorted sets (geo) | "Nearby" queries |
| Streams | Streams | Event processing |
Interview: Redis comes up constantly in system design, and the strong move is reaching for it with a specific use case and feature in mind - not just "add Redis to make it fast." Saying "I'll use Redis sorted sets for the leaderboard," "Redis atomic counters for rate limiting," or "Redis Pub/Sub to broadcast updates to the WebSocket servers" shows you know how Redis solves the problem, not just that it's fast. Knowing the mapping from use case to Redis feature is exactly the depth that distinguishes someone who's used Redis from someone who's only heard of it.
The bottom line
Redis is far more than a cache. Its rich set of in-memory data structures makes it the go-to tool for ten common jobs: caching, session storage, rate limiting, leaderboards (sorted sets), counting and analytics (atomic counters), queues (lists), real-time messaging (Pub/Sub), distributed locks (atomic operations), geospatial queries, and event streaming (Streams). The unifying thread is that each leans on Redis's speed and the right purpose-built data structure for the job.
Know the mapping from use case to Redis feature, and Redis becomes a versatile tool you reach for deliberately across a system - not just a box labeled "cache." We cover Redis and the role of in-memory stores across System Design Fundamentals.
Go deeper
- Redis Documentation - the authoritative source on Redis features and data structures.
- Redis Data Types - the structures behind these use cases.
- Redis (Wikipedia) - overview and common applications.
- Designing Data-Intensive Applications - in-memory stores and caching in context.