Most teams reach for Redis as a simple key-value cache and never look further, which leaves a remarkable amount of capability on the table. Redis is a fast, versatile data structure server, and several problems that teams solve by building bespoke infrastructure are better handled by a Redis pattern they already have running. Here are seven that earn their place in production.
1. Caching, done deliberately
Caching is the obvious use, but doing it well takes thought. Decide on sensible expiry, choose between lazy-loading on miss and writing through on update, and plan for the thundering herd when a popular key expires and every request stampedes the database at once. Done right, a cache is the cheapest database performance win available.
2. Rate limiting
Redis is ideal for rate limiting because counters are atomic and expiry is built in. A sliding-window or token-bucket limiter backed by Redis protects your APIs from abuse and accidental overload with a few operations, and it works across many application instances because the state lives in one shared place. This is a core building block of the controls in our API security checklist.
3. Distributed locks
When multiple instances must coordinate so that only one performs a task at a time, a Redis lock with a sensible timeout is a pragmatic solution. It needs care around expiry and ownership to avoid two workers believing they hold the lock, but for many coordination problems it is far simpler than standing up a dedicated coordination service.
4. Pub/sub and lightweight messaging
Redis pub/sub lets services broadcast messages to subscribers in real time, which is handy for live notifications and fan-out updates. It is fire-and-forget rather than durable, so for anything that must not be lost you want a stream or a real queue, but for ephemeral real-time signalling it is simple and fast, and it pairs naturally with event-driven designs.
5. Job queues
Backgrounding slow work keeps your request path fast. Redis-backed queues let you push tasks like sending email, generating reports, or processing uploads to worker processes that handle them asynchronously. Redis Streams add durability and consumer groups when you need delivery guarantees beyond a simple list.
6. Session and ephemeral state
Storing sessions in Redis lets a stateless application scale horizontally, because any instance can serve any user by reading shared session state. Built-in expiry handles cleanup automatically. The same approach suits any short-lived state that should survive a single request but does not belong in your primary database.
Know what Redis is not
The flip side of Redis being useful for so many things is the temptation to use it for everything, including jobs it is wrong for. It is an in-memory store, so the working set is bounded by memory and is more expensive per gigabyte than disk. It is not a durable primary database, and treating it as your only copy of important data is asking to lose it during a restart or eviction. For anything that must survive and be the source of truth, Redis complements a primary database rather than replacing it. The right mental model is a fast, versatile layer in front of and alongside your real datastore, handling hot reads, coordination, and ephemeral state, while the durable record of truth lives somewhere built for durability. Used within those limits it is superb; pushed beyond them it becomes a liability.
7. Real-time leaderboards and counters
Sorted sets make ranking and leaderboards trivial and fast, and atomic increments make accurate high-throughput counters easy. These are awkward and slow to do in a relational database under load, and a natural fit for Redis. If you want help deciding which of these patterns fit your system and wiring them up safely, our cloud and DevOps team uses them in production regularly.