What Data Structures Does Redis Support and When to Use Them?
Overview of Redis data structures — strings, hashes, lists, sets, sorted sets, streams — and when to use each in interviews.
Expected Interview Answer
Redis is an in-memory key-value store whose values can be rich data structures — strings, hashes, lists, sets, sorted sets, and streams — each offering different operations, so choosing the right structure for a use case avoids inefficient workarounds and unlocks native atomic operations.
Strings hold simple values or counters with atomic increment; hashes model an object's fields compactly, like a user profile; lists provide an ordered sequence useful for queues via push and pop; sets hold unique unordered members useful for tag membership and set operations like intersection; sorted sets attach a score to each member, enabling leaderboards and range queries by rank or score; and streams append immutable, ID-ordered entries suited to event logs and consumer groups. Because Redis keeps data in memory and offers atomic operations on each structure, choosing the structure that matches the access pattern is what makes Redis fast rather than just a generic cache.
- Structures map directly onto common access patterns, avoiding client-side workarounds
- Operations on each structure are atomic, avoiding race conditions
- In-memory storage gives sub-millisecond reads and writes
- Specialized structures like sorted sets solve problems (leaderboards) that plain key-value cannot
AI Mentor Explanation
Think of a live match dashboard: the current score is a simple string counter incremented ball by ball, the batting lineup is an ordered list you push players onto, and the list of players who have played this season is a set of unique names. The tournament leaderboard ranking every team by points is a sorted set, where each team's score determines its position instantly. Redis provides exactly these structures natively, so each part of the dashboard uses the data type that matches how it is actually queried.
Step-by-Step Explanation
Step 1
Identify the access pattern
Determine whether the use case needs a counter, an object, an ordered queue, unique membership, or ranking.
Step 2
Pick the matching structure
Use strings for counters, hashes for objects, lists for queues, sets for membership, sorted sets for ranking.
Step 3
Use native atomic commands
Operate with commands like INCR, HSET, LPUSH, SADD, or ZADD instead of read-modify-write in application code.
Step 4
Set expiration where appropriate
Apply TTLs (EXPIRE) for cache-style keys so Redis reclaims memory automatically.
What Interviewer Expects
- Naming and correctly describing the core Redis data structures
- Matching each structure to an appropriate real-world use case
- Understanding that operations on these structures are atomic
- Awareness that sorted sets solve ranking/leaderboard problems that plain strings cannot
Common Mistakes
- Treating Redis as only a simple string key-value cache
- Using a list for unique membership checks instead of a set
- Building a leaderboard by scanning and sorting in application code instead of using a sorted set
- Forgetting that Redis structures live in memory and sizing them without considering RAM limits
Best Answer (HR Friendly)
“Redis is not just a simple cache — it stores values as rich structures like hashes, lists, sets, and sorted sets, each suited to a different job. I pick the structure that matches the access pattern, like a sorted set for a leaderboard or a hash for an object's fields, so Redis handles the logic natively and stays extremely fast.”
Code Example
// Hash: store a user's profile fields
await redis.hSet('user:1001', { name: 'Ava', level: '12' });
// Sorted set: track a leaderboard scored by points
await redis.zAdd('leaderboard', [
{ score: 4200, value: 'user:1001' },
{ score: 3900, value: 'user:1002' }
]);
// Fetch top 10 players by rank, highest score first
const top10 = await redis.zRange('leaderboard', 0, 9, { REV: true });
// Atomic increment: bump a player's score after a match
await redis.zIncrBy('leaderboard', 150, 'user:1001');Follow-up Questions
- How does a Redis sorted set implement fast rank and range queries internally?
- When would you choose Redis Streams over a List for an event queue?
- How does Redis persistence (RDB vs AOF) affect durability of these structures?
- How do you avoid unbounded memory growth when using Redis sets or lists as caches?
MCQ Practice
1. Which Redis structure is best suited for building a real-time leaderboard?
A sorted set attaches a score to each member and supports fast rank and range queries, ideal for leaderboards.
2. Which Redis structure would you use to model a user object with multiple fields?
A hash stores field-value pairs compactly, matching how an object with multiple attributes is naturally modeled.
3. What guarantees do operations like INCR or HSET provide in Redis?
Redis commands on its data structures execute atomically, preventing race conditions from concurrent clients.
Flash Cards
What Redis structure fits a leaderboard? — A sorted set, which attaches a score to each member for fast rank and range queries.
What Redis structure fits an object with fields? — A hash, storing field-value pairs under one key.
What Redis structure fits unique membership? — A set, which holds unique unordered members and supports set operations like intersection.
Why use Redis native structures instead of raw strings? — They provide atomic, purpose-built operations that avoid inefficient application-side workarounds.