Redis in System Design: Data Structures and Use Cases

Redis is an in-memory data store that serves reads and writes in well under a millisecond and offers rich data structures, not just key-value strings: hashes, lists, sets, sorted sets, streams and more. In system design it's the default choice for caching, but also for session storage, rate limiting, leaderboards, counters, distributed locks with care, and lightweight queues. Knowing which data structure fits each problem, and what happens when Redis restarts, is what interviewers look for.

Data structures and what they're for

Common patterns

• Cache-aside: read Redis, fall back to the database on a miss and populate with a TTL. See cache strategies.
• Leaderboard: ZINCRBY leaderboard 10 user:42 on each score; ZREVRANGE leaderboard 0 9 WITHSCORES for the top ten; ZREVRANK for a user's position. Every operation is logarithmic.
• Rate limiting: INCR a per-user, per-minute key with an expiry for a fixed window, or a sorted set of timestamps for a sliding window. Use a Lua script so check-and-increment is atomic. See rate limiting.
• Sessions: a hash per session with an expiry, shared by all app servers, so the app servers stay stateless. See scalability.
• Counters: INCR is atomic, so millions of likes or views can be counted without races, flushed to the database periodically.
• Pub/sub and streams: pub/sub for fire-and-forget fan-out (no persistence); streams when messages must be durable and acknowledged.

Redis runs commands one at a time on a single main thread, so each command is atomic. That's why INCR and Lua scripts need no locks, and also why one slow command (KEYS * on millions of keys) blocks everything. Use SCAN instead.

Persistence and durability

Treat Redis as a cache unless you've deliberately configured and tested durability. If losing its contents would lose business data, that data should also live in a durable database.

Memory and eviction

Everything lives in RAM, so set maxmemory and an eviction policy such as allkeys-lru for caches (evict the least recently used keys) or volatile-ttl to evict keys closest to expiry. Without a limit, memory grows until the process is killed. Use TTLs on cache keys, keep values small, and watch for big keys (a hash with millions of fields) that are slow to read and delete. See cache eviction.

Scaling and availability

• Replication: a primary with replicas for read scaling and failover. Replication is asynchronous, so a failover can lose the last writes.
• Sentinel or managed failover: monitors the primary and promotes a replica automatically.
• Redis Cluster: shards keys across primaries using 16,384 hash slots; multi-key operations work only when keys share a slot, which you can force with hash tags such as {user42}:cart and {user42}:profile.
• Hot keys: a single very popular key can overload one shard; replicate it or cache it in-process. See hot partitions.
• Locks: Redis-based locks are fine for efficiency (avoid duplicate work) but need fencing tokens when correctness depends on them. See distributed locks.