Introduction to Redis

You’ve definitely heard this one before:

• A senior dev looks at a slow page and says, “just put it in Redis.”
• Everyone nods like they get it, and the page magically gets faster.
• But what actually is this Redis thing, right? And why does throwing stuff into it make things quick?

So let’s clear it up properly. By the end of this lesson you’ll know what Redis is, why people reach for it, and where it fits in a real system. We’ll keep it beginner-correct. Simple, but not so simple that it becomes wrong.

🎯 Why Redis

Let’s start with the pain, because Redis only makes sense once you feel the problem.

Say Alex builds a web app. There’s a database holding all the data, and there’s the app server handling requests. Now two annoying things keep happening:

• The database is slow for hot data. Some bits of data get asked for again and again, like a popular product or a user’s profile. Every single request goes back to the database, and the database has to do real work each time. That gets slow and expensive.
• App memory doesn’t stick around. Sure, the app server can keep stuff in its own memory to go faster. But the moment it restarts, that memory is wiped clean. So everything saved there is just gone.
• App memory isn’t shared. And when you run more than one server (which you always do at scale), each one has its own separate memory. Server A doesn’t know what Server B remembered. So they can’t share anything.

So Alex needs a spot that’s fast like memory, but also shared across all the servers and not tied to any one of them. That spot is Redis.

⚡ What is Redis

Here’s the plain definition. Redis is an in-memory key-value data store. That’s a mouthful, so let’s break the two scary words apart.

• In-memory means it keeps its data in RAM, the computer’s fast working memory, instead of on a hard disk. RAM is way faster to read from than a disk. That’s the whole secret behind Redis being quick.
• Key-value means you store things as simple pairs: a key (a name you pick) and a value (the data). It’s just like a dictionary or a labelled box. You hand it a key, it hands you back the value. No tables, no joins, no complicated queries.

A few more things worth knowing right away:

• Redis is famous for being really fast. Most operations finish in well under a millisecond, because it’s all happening in memory.
• It can store more than just plain text. It supports rich data types like lists and sets, which we’ll see in a second.
• It’s often called a cache, but it’s a bit more than that. A cache is just a fast temporary store for data you want to grab again quickly. Redis is great at being a cache, but people use it for other jobs too.

The most common way people use Redis is the cache-aside pattern. The idea is dead simple: check Redis first, and only bother the database if Redis doesn’t have it.

So the first request is a little slow because it hits the database. But it stashes a copy in Redis on the way out. Every request after that gets the fast answer straight from memory. That moment when Redis has the data is called a cache hit, and when it doesn’t, it’s a cache miss.

🧱 Redis Data Types

This is where Redis really shines over a plain “string in, string out” cache. The value you store doesn’t have to be just text. Redis understands a handful of useful shapes, and picking the right one makes your life easier.

You don’t need to memorise these. Just remember the headline: Redis isn’t only for plain strings. When you need a ranked leaderboard or a quick queue, there’s usually a built-in type that fits.

⌨️ Basic Commands

Let’s actually touch Redis now. The commands are short and read almost like English, so don’t worry. Here are the three you’ll use the most.

SET user:1 "Alex"
GET user:1
EXPIRE user:1 60

Let’s go through them one line at a time:

• SET user:1 "Alex" stores the value "Alex" under the key user:1. The user:1 is just a name we picked. People like using colons like this to keep keys organized, so user:1 means “user with id 1”.
• GET user:1 asks for whatever is stored under user:1. Redis hands back "Alex". That’s the whole read.
• EXPIRE user:1 60 sets a timer. After 60 seconds, Redis automatically deletes that key. This is huge for caching, because you usually don’t want cached data hanging around forever.

That last one points at something important. This automatic-deletion-after-some-time is called a TTL, short for “time to live”. You set a TTL so old cached data clears itself out, and the next request goes and fetches a fresh copy from the database.

🛠️ What People Use Redis For

Okay so we know what it is. Now where does it actually show up in real systems? Here are the big ones you’ll keep bumping into.

• Caching database results. This is the classic. Save the answer to a slow or repeated query in Redis, so the next request skips the database entirely.
• Session storage. When you log in, the server needs to remember “this person is Alex and they’re logged in”. Storing that session in Redis means any of your servers can read it, so logins work no matter which server handles your next request.
• Leaderboards. That sorted set type makes ranking effortless. Add players with their scores, and Redis keeps them sorted, so “top 10 players” is instant.
• Rate limiting. Want to stop someone overloading your API? Keep a counter in Redis per user, bump it on each request, and give it a TTL. If the count goes over the limit in that window, you block them.
• Queues and messaging. Lists and Redis’s other features let you pass jobs between services, like “send this email” landing in a queue for a worker to pick up later.

Notice the theme across all of these: they all need something fast and shared. That’s Redis’s sweet spot.

⚠️ Things to Know

Redis is great, but it’s not magic. A few honest limits to keep in your head.

• It lives in RAM, so it’s limited by RAM. Memory is fast but it’s smaller and pricier than disk. You can’t dump your entire database into Redis. You keep the hot, frequently-used stuff there, not everything.
• Data can be lost. Because it’s in memory, a crash or restart can wipe it if you haven’t told it to save. Redis does offer ways to write data to disk so it survives a restart. The two main ones are RDB, which takes snapshots every so often, and AOF, which logs every change. With persistence on, you’re much safer, but for a pure cache people often don’t even bother.
• It’s not your main database. Redis is brilliant as a fast layer, but it’s not built to be the one place that safely holds all your important data forever. Your database is still the source of truth. Redis is the fast helper sitting in front of it.
• It runs commands one at a time. Redis processes commands single-threaded, meaning it handles one command at a time in order. That sounds slow but it isn’t, because each command is so quick. It does mean one giant slow command can hold up everyone else, so you avoid those.

⚠️ Common Mistakes and Misconceptions

A few things trip people up early. Let’s clear them out so you don’t say them in an interview.

• “Redis can replace my database.” No. Redis is a fast layer in front of your database, not a replacement for it. Your database is still where the real, durable data lives. Redis holds copies and temporary things.
• “Data in Redis is always safe.” Not by default. It’s in memory, so a restart can lose it unless you’ve turned on persistence. Treat anything in Redis as droppable unless you’ve planned otherwise.
• “Once it’s cached, I’m done.” This is the stale-data trap. The real data in your database changes, but the old copy sits in Redis happily serving wrong answers. That’s why you use a TTL or clear the cached key when the data updates.
• “Redis is just a string cache.” It’s much more. Hashes, sets, sorted sets, and lists let it do leaderboards, queues, and structured data, not just plain text.

🛠️ Design Challenge

Try this one yourself to lock it in.

Imagine you’re building a news website, and the homepage shows the “top 5 trending articles”. This list is expensive to compute and gets viewed millions of times an hour. Think through how you’d use Redis here:

• Which data type fits a ranked “top 5” list?
• Where in the request flow do you check Redis, and when do you fall back to the database?
• What TTL would you put on it, so the trending list updates but you still serve most requests from cache?

There’s no single right answer. The point is to reason about hits, misses, and freshness, which is exactly how you’d talk through caching in an interview.

🧩 What You’ve Learned

You can now explain what Redis is and where it fits. Here’s what you’ve picked up.

• ✅ Redis is an in-memory key-value store, so it’s fast but lives in RAM.
• ✅ It solves the problem of slow hot-data reads and unshared, forgetful app memory.
• ✅ The cache-aside pattern checks Redis first and falls back to the database on a miss.
• ✅ It supports rich data types: strings, lists, hashes, sets, and sorted sets.
• ✅ Core commands are simple: SET, GET, and EXPIRE for a TTL.
• ✅ People use it for caching, sessions, leaderboards, rate limiting, and queues.
• ✅ It’s RAM-limited, can lose data without persistence (RDB/AOF), and isn’t a replacement for your main database.

🚀 What’s Next?

You’ve got the what and the why of Redis. Next, let’s zoom out and in.

• Introduction to Caching covers the bigger picture of why caching works and where caches live across a system.
• Cache Eviction Policies digs into what happens when the cache fills up, and how Redis decides which data to throw out (like LRU and LFU).

Get those down and you’ll have a solid grip on the caching questions that show up in almost every system design interview.