Topic 1.6
Choosing the Right Structure: A Decision Guide
In one line
Pick the structure from the question you must answer: "what's the value" (string), "what's this object's field" (hash), "what came next" (list or stream), "is it a member" (set), "what's the rank or range" (sorted set), "roughly how many unique" (HyperLogLog), "which bit" (bitmap), "what's nearby" (geo).
Think of it like this
A carpenter's toolbox. You can drive a screw with a hammer, but it's slow and it damages the wood. Picking the right tool first is most of the craft. In Redis, the wrong structure means extra round trips, race conditions and O(N) scans.
Key ideas
- 01
Start from the access pattern, not the data. List every read and write the feature needs ("increment", "top 10", "is member", "all fields", "oldest first"), then pick the structure whose commands answer those directly and atomically.
- 02
Check the cost of the worst query at your largest realistic size: 10 elements or 10 million? An O(N) command is fine on a 50-element hash and an outage on a 5M-element one.
- 03
Check memory per element: strings and hashes cost about 50–100 bytes of overhead per key; members inside a hash, set or sorted set are cheaper per element than separate keys; HyperLogLog is fixed at 12 KB; bitmaps cost 1 bit per possible ID. Estimate before you build.
- 04
Check atomicity needs: if one user action must update two structures, can you do it with one command,
MULTI, or Lua? Do the keys share a slot in Cluster? - 05
Check lifecycle: how does each key end? TTL, trimming (
LTRIM,XTRIM,ZREMRANGEBYSCORE), or explicit deletion. Unbounded structures are tomorrow's big keys.
Code & diagrams
Structure Typical op Complexity Watch out for
----------- --------------------- ------------- -------------------------------
String GET / SET / INCR O(1) values > 100 KB, lost TTL on SET
Hash HGET / HSET / HINCRBY O(1) HGETALL on huge hashes
List LPUSH / RPOP O(1) LRANGE 0 -1, LINDEX in the middle
Set SADD / SISMEMBER O(1) SMEMBERS, SINTER of huge sets
Sorted set ZADD / ZRANK / ZRANGE O(log N)(+M) ZRANGE 0 -1, float precision
Stream XADD / XREADGROUP O(1) / O(M) unbounded growth without XTRIM
HyperLogLog PFADD / PFCOUNT O(1) ~0.81% error, no membership
Bitmap SETBIT / BITCOUNT O(1) / O(N) sparse huge offsets allocate memory
Geo GEOADD / GEOSEARCH O(log N) / +M hot regions, stale positionsInterview problem
The problem
Pick the structures for a live-quiz app
A live quiz show has 2M concurrent players. You need: each player's current score, a live top-20 board, each player's rank, which questions a player has answered (to prevent double answers), an approximate count of unique players today, and a feed of the last 50 events in the show. Choose structures and commands.
You're given
- 2M players
- One question every 30 seconds
- Answers within 10 seconds
The interviewer follows up
Why not store each player as a hash with score and answers?
Explain it without notes
Describe your process for choosing a Redis structure for a new feature.
Why is estimating memory per element part of choosing a structure?
Practice
For a URL shortener, choose structures for: code → URL lookup, click counts per code, unique visitors per code per day, and the 10 most-clicked links today.
Trade-offs
- ↔
Exactness vs memory: sets and sorted sets are exact; HyperLogLog and Bloom filters trade exactness for fixed, tiny memory.
- ↔
One structure per feature vs combining: combining (score in a sorted set, details in a hash) avoids duplication but means two keys to keep consistent.
Done when you can
I can choose a structure from a list of required operations.
I know each structure's typical complexity and its dangerous commands.
I estimate memory and plan key lifecycles before building.