Redis in Practice: Cache Design, Message Queues, Distributed Locks, and High-Availability Architecture
Redis (Remote Dictionary Server), initially developed by Salvatore Sanfilippo in 2009, is known for exceptional performance (~1 million read/write ops/sec single-threaded) and rich data structures. Compared to Memcached, Redis provides String, List, Hash, Set, Sorted Set, HyperLogLog, Bitmap, and Stream — making it suitable for far more than simple caching.
Core Data Structures and Use Cases
String: basic type, stores up to 512MB. Common uses: session tokens (`SET session:xyz “{…}” EX 3600`), atomic counters (`INCR page:views:post:123`), distributed locks (`SET lock:resource “owner” NX EX 30`, NX = set only if absent).
Sorted Set: each member has an associated score, ordered by score. Ideal for real-time leaderboards: `ZADD leaderboard 9850 “user:42″` adds score, `ZREVRANGE leaderboard 0 9 WITHSCORES` gets top 10, `ZRANK leaderboard “user:42″` queries rank — all O(log N).
Stream: log data structure introduced in Redis 5.0, supporting persistence, consumer groups, and ACK — Redis’s built-in lightweight message queue, similar to a simplified Kafka, suitable for reliable event streams without Kafka’s complexity.
High Availability: Sentinel and Cluster
Standalone Redis suits development and low-load scenarios. Production HA uses Redis Sentinel (primary-replica replication + automatic failover, suitable for single-primary scenarios) or Redis Cluster (data auto-sharded across 16,384 slots, horizontal scaling for data exceeding single-node memory). See our distributed systems architecture guide for Redis’s role in systems design.
