NoSQL · Data models beyond tables
Which Redis data structures would you use and when?
Short answer
Strings, hashes, lists, sets, sorted sets and streams each map to different access patterns. Choose by the operation you need, such as ranking, queueing, uniqueness or counters.
Redis keeps data in memory and exposes atomic operations on each structure. The value is not just speed but the server-side operations, such as incrementing a counter or popping from a list, which avoid read-modify-write races in the client.
SET page:home:views 0
INCR page:home:views
HSET user:7 name "Asha" plan "pro"
HGET user:7 plan
LPUSH jobs:email "job_1"
BRPOP jobs:email 5
SADD post:42:likes user_7
SCARD post:42:likes
ZADD leaderboard 1200 user_7
ZREVRANGE leaderboard 0 9 WITHSCORES
XADD events * type "signup" userId 7Mapping patterns to structures
- String: counters, cached JSON, locks with NX and expiry
- Hash: objects with field-level reads and writes
- List: queues and recent items, with blocking pops
- Set: uniqueness and membership checks
- Sorted set: rankings and time-ordered indexes by score
- Stream: append-only event logs with consumer groups
Complexity matters at scale. Most single-key operations are O(1) or O(log N), but commands such as KEYS, SMEMBERS on a huge set or ZRANGE over a large range can block the single-threaded event loop. Use SCAN instead of KEYS and keep individual values and collections bounded.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why is KEYS dangerous in production?
- 2How would you implement a rate limiter in Redis?
- 3What is a big key and how do you find one?
- 4When would you use a stream instead of a list?
Say it in the interview
I choose the Redis structure by the operation, not by the data shape. Strings handle counters and cached values, hashes hold objects, lists work as queues, sets give membership and uniqueness, sorted sets give rankings, and streams give an event log with consumer groups. The server-side atomic operations are often more valuable than raw speed. I avoid KEYS and unbounded collections, because command execution is single-threaded and one big operation can stall everything.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.