How to Learn Redis Data Structures (Without Mixing Up Sets, Hashes, and Lists)

You've watched three Redis intros this month. You can type SET and GET without looking them up. Then someone asks whether a shopping cart belongs in a hash or a list, and your brain goes blank.

That gap is normal. Most tutorials show the commands. They rarely give you a durable model for when each type wins. So you reopen the docs every time you design a key.

I still mix them up under pressure if I haven't practiced lately. The fix that worked was boring: pick one concrete job for each type, write it in my own words, and review those distinctions on a schedule instead of rewatching the same video.

Five types, five jobs

Strings are the default. One key, one value. Counters (INCR page views), feature flags, short-lived tokens, any single blob. A JSON document that you never update field-by-field can live in a string. The moment you need field-level updates, switch to a hash.

Hashes are field maps under one key. A user profile like user:42 with email, plan, last_login is the classic case. You HGET one field without pulling the whole object. Caching a Postgres row as a hash is common. My test: "named fields on one entity." If that fits, use a hash.

Lists are ordered sequences. Push and pop from either end. Job queues (LPUSH / BRPOP), recent activity feeds, "last N items" windows. Order matters and duplicates are allowed. Need uniqueness? Look at a set.

Sets are unordered unique members. Tags on a post, online user IDs, intersections of two cohorts. SADD, SISMEMBER, SINTER. No duplicates, no ranking. If you care about "first" or "highest score," jump to sorted sets.

Sorted sets add a score to each unique member. Leaderboards, delayed jobs, rate-limit windows by timestamp. ZADD, ZRANGE, ZREVRANGE BYSCORE. Unique members, ordered by score. I once spent a week stuffing scores into list indexes before someone pointed me at zsets. Don't do that.

Gut checks I keep on a sticky note: one value → string; named fields on one thing → hash; ordered with duplicates OK → list; unique with no order → set; unique plus score → sorted set. Command names stick once the jobs are clear.

Why rewatching doesn't stick

Passive rewatching feels useful. It rarely is. You nod when the instructor says "use a hash for the session," then fail the same call two days later in a PR review.

What helps is retrieval. Close the tab. Ask yourself: cart line items with qty per SKU, hash or list? (Hash keyed by user, fields as SKU → qty works for the simple shape.) Logged-in socket IDs belong in a set. Top 10 scores this week need a sorted set.

Wrong answers show which boundary is still fuzzy. Right answers that took ten seconds of staring count too. That friction is the learning. I keep eight scenarios in a note and answer them from memory once a week. Pen and paper is enough. The point is choosing a type with the docs closed.

Turning Redis tutorials into something you can recall

Learning from YouTube walkthroughs, Redis University clips, or long docs creates a volume problem. You save twelve tabs. You remember two slogans. By Friday the type distinctions are mushy again.

I dump the videos and articles into Recl instead of Watch Later. Share-sheet save, or the Chrome extension with Ctrl/Cmd+Shift+S, parks the link. Recl builds a TL;DR, key takeaways, and chapters, then files the save under library topics so Redis material doesn't drown in random bookmarks.

Takeaways beat a full rewatch. A useful line says "hashes for entity fields; lists for queues" in words you can quiz yourself on. When a takeaway feels vague, I rewrite it. Owning the wording helps it stick.

Spaced repetition does the rest. Recl nudges you to recall those takeaways on a growing schedule and runs short quizzes, so the string-vs-hash call shows up again before it evaporates. Those nudges land in the Today tab. Notes come find you.

Ask your library helps mid-design. I'll ask where I saved the bit about sorted sets for delayed jobs and get an answer with sources, instead of scrolling a month of history. Public shelves can live on library.recl.app; day to day I keep Redis notes private. Folders and auto topics keep one Redis topic and one caching-patterns topic without a Sunday folder rebuild.

A small weekly loop

Monday: save one Redis talk or doc section you'll actually use. Skip the twelve "someday" videos.

Tuesday: skim the takeaways. Rewrite one sentence if it sounds canned. Add a note like "cart = hash" if that was the lesson.

Midweek: answer two scenario questions from memory. Cart shape, rate limiter, online presence, leaderboard. Match whatever is on your desk.

Friday: spend two minutes on whatever is due for recall. Then stop.

You're locking the type decision so design reviews stop being a coin flip. Memorizing every command is optional.

The mix-up that cost a weekend

Early on I stored a per-user feed as a set because "unique posts" sounded right. Product then asked for chronological order. Sets ignore order. I moved to a list, lost uniqueness, and bolted on app-level checks. A sorted set with timestamp scores would have covered both. That migration ate a weekend.

I had already read the docs. What I skipped was practicing the decision under a real constraint until production forced it. Scenario quizzes close that gap earlier.

If your Redis model still wobbles, start with the five jobs above. Save the tutorials you'll revisit. Review the distinctions on a schedule. Recl just makes the loop less manual: save what matters, get takeaways you can quiz, and let spaced repetition bring the type choices back before you forget them.

Author: Asutosh. I build Recl. Save what matters. Recall it forever. https://www.recl.app