Redis patterns are quietly the difference between a backend that scales gracefully and one that hits a wall the first time traffic spikes. Most teams use Redis as a glorified key-value cache and miss 80% of what makes it powerful. The data structures (sorted sets, streams, hyperloglog), the atomic operations, and the pub/sub primitives let you implement rate limiting, leaderboards, distributed locks, and queue patterns in single-digit milliseconds. Here is what to actually use.
Table of Contents
Cache-Aside Is Just the Starting Point
The basic cache-aside pattern (check Redis, fall back to DB, populate Redis) is fine but solves the easy half of caching. The hard half is invalidation, stampedes, and stale data. Use TTL plus probabilistic early refresh to avoid thundering herds, and tag-based invalidation when one DB write affects multiple cache keys.
For read-heavy workloads, write-through caching (update Redis and DB in the same transaction) eliminates staleness windows. The official Redis patterns documentation covers the variants in depth.
Rate Limiting With Sorted Sets
A sliding-window rate limiter in Redis is roughly 10 lines of code. Use a sorted set keyed by user ID, score = timestamp, member = unique request ID. On each request, ZADD the new entry, ZREMRANGEBYSCORE entries older than the window, and ZCARD to count.
This pattern handles distributed rate limiting across N app servers without coordination overhead because Redis is the coordinator. Combine with our API design best practices for a complete rate limiting story including headers and 429 responses.
Distributed Locks With SET NX EX
Distributed locking with Redis is famously tricky (see the Redlock debate), but for non-safety-critical use cases (idempotency, preventing duplicate jobs) the simple `SET key value NX EX 30` pattern works fine. Set a unique value per lock holder, check it before releasing.
The Redlock algorithm with multiple Redis nodes is needed when correctness depends on mutual exclusion under network partitions. Most app-level locking does not need that strictness — pick the simpler pattern unless you have a specific reason.
Streams for Lightweight Queues
Redis Streams (added in 5.0) implement an append-only log with consumer groups, similar to Kafka but with a fraction of the operational overhead. For workloads up to a few hundred thousand messages per second on a single instance, Streams are dramatically simpler than running Kafka.
Producers XADD messages, consumers XREADGROUP with their consumer ID. Acknowledgments via XACK, dead-letter handling via XPENDING. Persistence through RDB and AOF means messages survive restarts.
Leaderboards and Trending Lists
Sorted sets (ZSETs) make leaderboards trivial. ZADD the score, ZREVRANGE to get the top N, ZRANK to get a user’s rank. All operations are logarithmic time. A million-user leaderboard fits comfortably in a single Redis instance and answers queries in well under a millisecond.
Trending content lists work the same way — use timestamp-based scores with periodic ZREMRANGEBYSCORE to drop old entries. The ZADD command reference documents the various score modifiers.
Wrap Up
Redis patterns done right turn a basic key-value cache into a Swiss Army knife for distributed system primitives. Sorted sets for rate limiting and leaderboards, streams for queues, NX-set for locks, hashes for object storage. Master four or five patterns and Redis becomes the most versatile tool in your stack. Pair with database optimization techniques on the persistent layer for a complete data tier.
Frequently Asked Questions
Should I use Redis or Memcached?
Redis for almost everything. Memcached is faster at pure cache workloads on multi-core but Redis’s data structures, persistence, and replication make it the obvious default. The performance gap rarely matters.
How do I scale Redis beyond a single instance?
Read replicas for read-heavy workloads, Redis Cluster for sharded writes. Most apps never outgrow a single primary with replicas. Redis Cluster adds complexity — only adopt when you need it.
Is Redis durable?
With AOF (append-only file) at fsync=everysec, yes — you lose at most one second of writes on crash. RDB snapshots add point-in-time backups. Treat Redis as durable for cache and queue use cases, not as a primary store for irreplaceable data.
What’s the difference between Redis and Valkey?
Valkey is the open-source Redis fork after Redis Inc changed the license in 2024. AWS, Google, and others backed Valkey. APIs are compatible; pick based on your hosting provider’s support.
How much memory do I need?
Size for working set + 25% headroom. Redis is single-threaded for command processing; CPU rarely bottlenecks before memory does. Monitor `used_memory_peak` and alert at 80% of `maxmemory`.
