In this chapter
We'll meet all six of Redis's real data structures — Strings, Lists, Sets, Sorted Sets, Hashes, and Streams — most of them runnable in the Playground.
The Problem in Real Life
The stock counter fix works — one key, one number, one atomic read. But Sarah's list of "things that need to be fast" keeps growing, and not all of it is a single number. A running list of the last few orders. The set of sellers who've had at least one sale today. A live ranking of the best-selling items, updating by the second.
None of those are a single value sitting behind a single key. Sarah goes looking for what Redis actually offers beyond plain strings, and finds a lot more than she expected.
It's not just a big dictionary of strings. There's a whole toolbox in here.
Sarah
One Shape vs. Five (and a Half)
Lists keep order
An ordered sequence of values — perfect for a queue or a recent-activity feed.
Sets guarantee uniqueness
No duplicates, ever — ideal for "has this already happened" questions.
Sorted Sets stay ordered by score
Every member carries a number — Redis keeps it sorted automatically, no separate sort step.
Hashes group related fields
One key, several fields — a whole small object in a single round trip.
Redis Data Structures
Every Redis value is stored under a key, but the value itself can take several different shapes — each one built for a different kind of "fast" GreenMart actually needs.
| Structure | Looks like | Good for |
|---|---|---|
| String | A single value — text or a number | A cached value, a counter, a flag |
| List | An ordered sequence of values | A queue, a recent-activity feed |
| Set | An unordered collection of unique values | Membership checks — "has this happened yet?" |
| Sorted Set | A set where every member also has a score | Rankings, leaderboards, anything ordered by a number |
| Hash | A single key holding multiple field-value pairs | One record's worth of related fields — a session, an object's live stats |
| Stream | An append-only log of timestamped entries | A durable, replayable sequence of events |
The simplest shape, already in use since the first chapter — one key, one value.
SET cart:1042 "3 items"GET cart:1042
A List keeps values in the order they were added. LPUSH adds to the front; LRANGE key 0 -1 reads the whole thing back — here, the most recently pushed order lands first.
LPUSH recent:orders "order-4471"LPUSH recent:orders "order-4472"LRANGE recent:orders 0 -1
A Set holds unique values — adding "sel-01" twice doesn't create a duplicate. Perfect for "has this already happened" questions: GreenMart doesn't need to know how many times sel-01 sold something today, just that they did.
SADD sellers:active-today "sel-01"SADD sellers:active-today "sel-02"SADD sellers:active-today "sel-01"SMEMBERS sellers:active-today
A Sorted Set is a Set where every member also carries a numeric score — here, sales count. Redis keeps it ordered by score automatically; no separate sort step needed on every read. This Act comes back to sorted sets properly for real leaderboards a couple of chapters from now.
ZADD top:sellers 12 "sel-01"ZADD top:sellers 7 "sel-02"ZRANGE top:sellers 0 -1 WITHSCORES
A Hash is a single key holding several field-value pairs, like a small object — one round trip fetches every stat instead of maintaining a separate key per field.
HSET stats:lst-fast-charger-20w views 412 cartAdds 38HGETALL stats:lst-fast-charger-20w
One more structure, worth knowing even without a runnable example here: a Stream. Where a List is just an ordered sequence Sarah can push to and read from, a Stream is built specifically to be an append-only, timestamped log — entries never disappear on their own, multiple independent readers can each track their own position through it, and it's genuinely replayable from any point. It's Redis's answer when what's actually needed is closer to a durable event log than a simple queue — this Act comes back to exactly that distinction in the pub/sub chapter ahead.
Six shapes, one memory-speed database underneath every one of them. Which shape fits which of GreenMart's problems is the real skill this Act keeps building — not memorizing all six, but recognizing which one a given problem actually looks like.
Key Takeaway
Redis isn't a big dictionary of strings with a fast disk swapped for memory. Five real structures — plus Streams — each shaped for a different kind of problem, all living at the same memory speed.
Why This Matters
Every remaining chapter in this Act reaches for one of these shapes for a specific, real reason — Sets and Sorted Sets for rate limiting and leaderboards, Hashes for sessions, Lists for queues. Knowing the shapes now means the rest of this Act is about applying them, not learning new syntax every chapter.
GreenMart's toolbox now has real shapes, not just a bigger string store. But every one of these values is still sitting in memory forever unless Sarah does something about it — and "forever" is exactly the wrong answer for a shopping cart nobody came back to.