Redis is one of the most versatile tools in the modern engineering stack. Teams that use it only as a cache are leaving significant capability on the table. Here are the patterns we reach for regularly.
1. Distributed rate limiting with sliding windows
A single-server rate limiter breaks when you scale horizontally. Redis provides shared state across all instances. Use a sorted set with timestamps as scores — add the current timestamp, remove entries older than the window, count remaining entries. The Lua scripting capability makes this atomic and race-condition-free.
2. Distributed locks
For tasks that must run on exactly one node — cron jobs, payment processing, inventory updates — use Redis's Redlock algorithm. The key insight: SET with NX (only if not exists) and EX (expiry) in a single atomic operation gives you a lock that automatically expires if the holder crashes.
3. Session storage
Redis as a session store gives you: fast reads (sub-millisecond), automatic expiry (no cleanup jobs), and horizontal scalability. More importantly, it decouples session state from application instances — you can deploy new code and kill old instances without invalidating sessions.
4. Real-time leaderboards with sorted sets
Redis sorted sets maintain a ordered set with scores. ZADD, ZRANK, ZRANGE — adding a member, getting its rank, and getting the top N members are all O(log N) operations. Building a live leaderboard that updates in real-time across millions of users is a single sorted set command per game event.
5. Pub/Sub for real-time features
Redis pub/sub enables lightweight event-driven communication between services. Perfect for: live notifications, chat applications, real-time dashboards, and invalidating caches across multiple application instances. Not suitable for persistent messaging — events are fire-and-forget. Use Redis Streams for durable messaging.
6. Redis Streams as a lightweight queue
Redis Streams provide persistent, consumer-group-aware message queues. Unlike pub/sub, messages survive consumer restarts. Consumer groups allow multiple consumers to process the same stream in parallel without processing the same message twice. For moderate-volume job queues (thousands per second), Streams beats the overhead of Kafka significantly.
7. Probabilistic data structures
HyperLogLog for approximate unique counts (unique page views per day) with minimal memory. Bloom filters for membership testing (has this user seen this notification?) with constant memory regardless of set size. Cuckoo filters for deletable bloom filters. These solve specific problems at a fraction of the cost of exact data structures.