What Is Redis? The Only Beginner's Guide You'll Ever Need (With Real Code, 2026)

Caching, sessions, leaderboards, OTPs, rate limiting — explained with grocery stores, hotel receptionists, and a healthy dose of sarcasm.

Imagine you own a small grocery store.

Every time a customer asks for a packet of rice, you lock the shop, drive 5 kilometers to your warehouse, grab the packet, drive back, hand it over — and then do the exact same round trip for the next customer.

And the next.

And the next.

You'd go bankrupt from fuel costs alone before lunch.

Now imagine something smarter: you keep today's bestsellers — rice, milk, bread, eggs — on a shelf right behind the counter. When someone asks for one of those, you grab it instantly. The warehouse is still there. You haven't replaced it. You've just added a much faster layer in front of it.

That shelf is Redis.

Every app you use does something similar. Instagram's feed loads before you've even finished tapping the icon. Spotify remembers your playlists instantly. Amazon never forgets what's in your cart, even after five tab closures and a browser crash. Millions of requests are hitting these systems every second — and if every single one had to go straight to the main database, your favorite apps would feel like dial-up internet.

So companies put a blazing-fast storage layer between the app and the database. Most of the time, that layer is Redis.

Redis (short for Remote Dictionary Server) is an open-source, in-memory data store that can serve data in under a millisecond. It's the engine behind caching, session management, queues, leaderboards, rate limiting, real-time messaging, and a dozen other things you use daily without knowing it. GitHub, Shopify, Discord, Stack Overflow, Twitch — they all lean on Redis, and not because it's trendy. Because it's stupidly fast and refreshingly simple.

By the end of this guide, you won't just know what Redis is. You'll understand why it exists, when to reach for it, and you'll have actually built something with it. No fluff, no unnecessary jargon — just the mental models that make Redis click.

What you'll learn

• What Redis actually is (in one sentence you'll never forget)
• Why it's absurdly fast
• The 6 core data structures — and when to use each
• How caching really works, request by request
• TTL: Redis's built-in self-cleaning superpower
• The 5 commands that cover 90% of real-world usage
• Two hands-on projects: a visitor counter and an OTP system

Let's go.

So... What Exactly Is Redis?

One sentence, before we go any deeper:

Redis is an incredibly fast in-memory database that remembers frequently used data, so your app doesn't have to keep bothering the main database for the same answer.

Let's unpack that.

Say you're running an online store. A customer opens the homepage, and your app asks the database for trending products, categories, user info, cart contents, and recommendations. A few seconds later, another customer visits — and your app asks the database for the exact same information, again.

Then another. And another. And another.

Imagine asking a friend the same question a thousand times an hour. Eventually they stop answering your calls. Databases feel the same way — the more redundant requests they get, the harder (and slower) they work.

Redis breaks that cycle by remembering the answer.

First request, no cache:

User → Application → Database ❌ (slow, does real work)

Redis stores the result. Second request:

User → Application → Redis ✅ (near-instant)

The database catches a break, your app gets faster, and your users stop staring at spinning loaders.

Think of your database as a massive library, and Redis as the five books you keep on your desk because you reach for them constantly. The library hasn't gone anywhere — you're just not walking across the building every time you need page 42.

This idea is called caching, and it's the single biggest reason Redis became a staple of modern backend engineering.

Why Is Redis So Fast?

Picture your desk. Notebook, laptop, phone — all within arm's reach. Need a pen? You grab it in half a second.

Now imagine that notebook is locked in a cupboard across the room. Every time you want to jot something down, you get up, walk over, unlock it, grab it, walk back, write one sentence, and repeat. Suddenly even simple tasks feel like a chore.

That's the difference between RAM and disk storage — and it's the entire reason Redis exists.

Redis keeps everything in RAM. Traditional databases mostly live on SSDs or HDDs. RAM is built for split-second access by the CPU; disks are built for durability, not speed.

Those numbers look close on paper, but look at the units. A nanosecond is one-billionth of a second. A microsecond is one-millionth. A millisecond is one-thousandth. RAM isn't "a bit faster" than disk — it's operating in an entirely different universe of speed.

Or, if numbers make your eyes glaze over:

• RAM = food already on your dining table
• SSD = food in your kitchen
• HDD = driving to the supermarket every time you're hungry

Same food. Wildly different wait times.

That's why Redis responds in under a millisecond — perfect for the data your app asks for over, and over, and over again.

But there's a catch. RAM is volatile — its contents vanish if the machine loses power or restarts. That's why Redis is (almost) never your only database. It works alongside something like PostgreSQL or MySQL: the database is the permanent vault, and Redis is the fast shelf in front of it. You're not replacing the storage room. You're just saving yourself a thousand trips to it.

When Should You Actually Reach for Redis?

Let's go back to that online store. A customer opens the homepage, and your app fetches the latest products, categories, best-sellers, and today's deals. A minute later, another customer loads the same homepage — and without a cache, your app asks the database to do the exact same work again.

The data hasn't changed. The database doesn't care. It just keeps grinding.

This is exactly where Redis earns its keep: instead of hammering the database with identical queries, your app stores the result in Redis for a short window. The next visitor gets an instant answer, and the database never even knows they showed up.

That's caching — the most common reason people use Redis. But it's really just the opening act. Here's the rest of the show:

🛒 Shopping Carts

Add five items on Amazon, refresh the page, and they're still there. Your cart doesn't need a permanent database write on every click — Redis can hold it temporarily and update it almost instantly.

🔐 Login Sessions

Sign into Gmail once, and you're not re-entering your password on every page. Your app stores a lightweight session, and Redis is one of the most popular places to keep it, since reading it back takes a fraction of a millisecond.

🚦 Rate Limiting

Someone tries to brute-force a login 5,000 times in a minute. Redis keeps a simple counter per IP address, and the moment it crosses your limit, further attempts get blocked. This is how a huge number of public APIs stay abuse-resistant.

🏆 Live Leaderboards

Millions of players, constantly shifting rankings. Re-sorting that in a traditional database on every request would be painfully slow. Redis has a purpose-built structure called Sorted Sets that's practically made for this job.

💬 Real-Time Chat

Send a message on Discord, and everyone in the channel sees it almost instantly. A lot of that speed comes from Redis shuttling messages between servers in real time.

⚡ Background Jobs

Upload a profile picture, and you're not stuck watching a spinner while it gets resized. Your app accepts the upload immediately, drops a task into a queue, and a background worker handles it seconds later — with Redis often powering that queue.

Notice the pattern? Every single one of these is about speed under pressure. Redis isn't trying to replace your primary database — it's there for the moments where even a one-second delay feels broken.

That gives you an architecture like this:

User → Application ──► Redis (checked first)
                          │
                          ▼
                    Cached Data
                          │
Application ──► Database (only if Redis has nothing)

Check Redis first. If it has the answer, return it immediately. If not, fall back to the database, save a copy in Redis for next time, and move on. That one simple pattern is responsible for saving millions of redundant database queries every single day — and it's a big part of how modern apps scale to millions of users without falling over.

How Does Redis Actually Store Data?

We've covered the why. Now let's talk about the how.

Imagine checking into a hotel. You hand over your luggage, and instead of digging through hundreds of bags every time someone asks for theirs, the receptionist tags each one with a room number.

Room 101 → Black Suitcase
Room 205 → Blue Backpack
Room 310 → Red Travel Bag

When a guest wants their bag back, the receptionist doesn't search — they just look up the room number.

Redis works the same way, using a key and a value. The key is the label. The value is the actual data.

Key                 Value
----------------------------------------
user:101            Ansh Srivastava
cart:101            iPhone, AirPods
otp:9876543210      481293
product:15          MacBook Pro

Instead of asking, "Search everything for a user named Ansh," your app just says, "Give me whatever's stored under user:101." Redis knows exactly where to look — no scanning, no searching, just a direct lookup. That's a big part of why it's so fast.

A quick real example

A customer named Rahul logs in. Your app might store:

Key: session:rahul

Value:
{
  "name": "Rahul",
  "loggedIn": true,
  "cartItems": 4
}

From then on, every page Rahul visits checks Redis instead of the main database. If the session exists, he stays logged in. If it's expired, Redis simply returns nothing, and he's asked to log in again — all in less time than it takes you to blink.

Values aren't just plain text

Here's the twist: Redis looks like a simple key-value store on the surface, but the value can be far more than a string. It can be a list, a set, a hash, a sorted set, a stream, and more. That flexibility is one of Redis's biggest strengths — instead of jamming every problem into the same shape, you pick the structure that actually fits. Let's look at those next.

Redis Data Structures: The Real Secret to Its Flexibility

Open a toolbox and you don't expect every tool to be a hammer. Sometimes you need a screwdriver, sometimes a wrench, sometimes a measuring tape. Same job category — different tools for different problems.

Redis is built the same way. Here are the ones you'll actually use.

📝 Strings — the sticky note

The simplest type. One key, one value. Perfect for a name, an OTP, a JWT, or a visitor count.

Key                  Value
------------------------------------
user:101:name        Ansh Srivastava
otp:9876543210       482913
website:views        15293

👤 Hashes — the ID card

A student has a name, roll number, branch, and CGPA. Instead of making five separate keys, a Hash groups it all under one:

student:101
  Name        Ansh
  Branch      CSE
  Semester    5
  CGPA        8.5

Great for user profiles, product details, and anything with multiple related fields.

🛒 Lists — the shopping cart

Add a laptop, then a mouse, then a keyboard — Redis remembers the order.

1. Laptop
2. Mouse
3. Keyboard

Used for shopping carts, notification feeds, recent searches, and job queues — anywhere order matters.

🎵 Sets — the duplicate-proof playlist

Try adding the same song to a Spotify playlist twice — it just gets ignored. A Redis Set works the same way: unique values only.

Tags: AI, Backend, Redis, Docker, Redis ❌ (ignored, already exists)

Perfect for tags, permissions, friend lists, and unique-visitor tracking.

🏆 Sorted Sets — the live leaderboard

Every value gets a score, and Redis keeps everything ranked automatically.

Alice   9800
Rahul   9200
Ansh    9100
John    8750

This is the backbone of gaming leaderboards, trending posts, and ranking systems.

🌊 Streams — the never-ending announcement board

Think of a railway station display — new announcements keep appearing, old ones stay in history. Streams are built for continuous events: payment notifications, IoT sensor data, order updates, activity logs.

The cheat sheet

Don't try to memorize all six on day one. Most developers start with Strings and Hashes, then pick up the rest naturally as real problems demand them.

Redis isn't powerful because it stores data. It's powerful because it gives you the right shape to store the right kind of data.

What Actually Happens When You Open a Website?

Let's trace a real request. You open Instagram, tap the app, and your feed appears in under a second.

Behind that "simple" moment is a small decision tree:

📱 You open Instagram
        │
        ▼
Backend Server
        │
        ▼
"Do I already have this data?"
        │
        ▼
      Redis

✅ Cache Hit

Redis already has the data — maybe thousands of people just requested the same trending posts. No need to bother the database at all.

You → Backend → Redis ✅ → Response

The page loads instantly, and your database gets to relax for a second.

❌ Cache Miss

First time anyone's asked for this particular data. Redis checks... and comes up empty.

You → Backend → Redis ❌ → Database

The backend falls back to the database, gets the answer — and here's the clever part — stores a copy in Redis before responding to you.

Database → Backend ──► Redis (saved for next time)
                    └─► Response (sent to you)

The next person asking for the same thing skips the database entirely. This pattern is called the Cache-Aside Pattern, and it's one of the most widely used caching strategies in production systems today.

Why this actually matters

Imagine a million people visit your site today. Without caching, that's potentially a million database queries. Now imagine 80% of those requests are for data that barely changes. With Redis absorbing the repeats, your database only has to deal with requests that genuinely need fresh data.

That's not just "faster." That's more scalable — your database stops working harder just because your user count went up.

How Redis Knows When to Forget (TTL)

You request a bank OTP. It shows up as:

482913

Now imagine that code never expired. Someone could reuse it next week. That's not a feature — that's a security incident waiting to happen.

Instead, OTPs typically die after 5 minutes, and Redis handles the countdown for you automatically. This is called TTL — Time To Live — essentially an alarm clock attached to every piece of data.

OTP
├── Created at 10:00 AM
├── Valid for 5 minutes
└── Deleted automatically at 10:05 AM

No cleanup scripts. No cron jobs. Redis just quietly takes the trash out.

Where you'll see TTL everywhere

All of this is data that's useful for a while, and useless after — exactly the kind of thing Redis was built to expire automatically.

A real example

You're building a movie ticket booking site. Thousands of people check the same showtimes. Instead of hitting the database every time, you cache the schedule for 10 minutes:

Movie Schedule → Store in Redis → TTL = 10 minutes → Auto-removed

Anyone visiting within that window gets an instant response. Once the timer runs out, the next request pulls fresh data and re-caches it. Fast and up to date — no trade-off required.

Redis isn't just about storing data quickly. It's about knowing exactly when that data stops being useful — which is what makes it perfect for OTPs, sessions, caches, and anything else with a shelf life.

Redis in 5 Commands

Most of your day-to-day Redis work boils down to a handful of commands. Here they are.

1. Store data — SET

SET user:101:name "Ansh"

2. Retrieve data — GET

GET user:101:name
# → "Ansh"

3. Delete data — DEL

DEL user:101:name

4. Auto-expire data — EXPIRE

SET otp:987654 "482913"
EXPIRE otp:987654 300

300 means 300 seconds. Five minutes later, it's gone — no cron job, no manual cleanup.

5. Increment a number — INCR

INCR website:visitors

If the value was 1024, it instantly becomes 1025 — atomically, with zero risk of two simultaneous visitors overwriting each other's count. This single command quietly powers view counters, like buttons, upvotes, and rate limiters across half the internet.

You genuinely don't need much more than these five to build something real. The rest of Redis's command set — and there's a lot of it — you'll pick up naturally as your projects grow.

🚀 Project #1: Build a Live Visitor Counter

Time to stop reading and start building. You just launched your blog, and every visitor should bump a counter — without hammering your database on every single page load.

Step 1 — Run Redis

docker run -d --name redis -p 6379:6379 redis

Step 2 — Install the client

npm install redis

Step 3 — Connect

import { createClient } from "redis";

const client = createClient();
await client.connect();

console.log("✅ Connected to Redis");

Step 4 — Count every visitor

app.get("/", async (req, res) => {
  const visitors = await client.incr("website:visitors");

  res.send(`
    <h1>Welcome 👋</h1>
    <h2>Total Visitors: ${visitors}</h2>
  `);
});

That's the whole feature. Every request bumps the counter by one — no race conditions, no manual math, no SQL gymnastics.

Why not just use MySQL for this?

Imagine your post goes viral and a million people show up in a day. If every visit triggers a database write, that's a million write operations hitting your relational database. Redis's INCR is atomic — meaning two visitors arriving at the exact same nanosecond still can't corrupt each other's count. It's built for exactly this kind of high-frequency, low-complexity workload — the same trick behind YouTube view counts, LinkedIn impressions, and Instagram likes.

One caveat: if Redis restarts without persistence enabled, this counter resets to zero. In production, you'd typically pair Redis (fast, real-time counting) with a real database (durable, long-term storage) — best of both worlds.

🔐 Project #2: Build an OTP Verification System

Let's build something a real login flow would actually use. A user enters their phone number, gets a 6-digit code, and that code needs to:

• ✅ Exist for exactly 5 minutes
• ✅ Work only once
• ✅ Disappear on its own afterward

This is Redis's home turf.

Step 1 — Generate the OTP

const otp = Math.floor(100000 + Math.random() * 900000);
// e.g. 482913

Step 2 — Store it with a TTL

await client.set("otp:9876543210", otp, { EX: 300 });

Step 3 — Verify it

const storedOTP = await client.get("otp:9876543210");

if (storedOTP === enteredOTP) {
  console.log("OTP Verified");
} else {
  console.log("Invalid OTP");
}

Step 4 — Prevent reuse

await client.del("otp:9876543210");

Once verified, the OTP is gone — permanently. Even if someone somehow intercepts it later, it's useless.

The full flow

User enters phone number
        ↓
Backend generates OTP
        ↓
Stored in Redis (5-minute TTL)
        ↓
SMS sent
        ↓
User enters OTP
        ↓
Compared against Redis
        ↓
Success ✅ → OTP deleted

Now imagine storing every OTP permanently in a SQL database instead. A year in, you'd be sitting on millions of dead rows nobody will ever query again. Redis solves this elegantly — the data exists only as long as it's useful, then it's gone. No cleanup scripts, no scheduled jobs, no manual housekeeping.

Final Thoughts

You started this article asking a simple question: "What is Redis?" But somewhere along the way, you picked up something more useful — why it exists.

You now know:

• Why caching exists, and why databases need a break sometimes
• Why RAM makes Redis absurdly fast
• How Redis fits alongside your database, not instead of it
• When to reach for Strings, Hashes, Lists, Sets, Sorted Sets, or Streams
• How TTL cleans up after itself automatically
• The five commands that cover most real-world usage
• How to actually build a visitor counter and an OTP system

Here's the bigger lesson, though: becoming a better developer isn't about collecting more tools — it's about understanding the problem each tool was built to solve. Redis wasn't invented because someone wanted "another database." It was invented because applications were slow, and someone decided that was unacceptable. Once you internalize the problem, choosing the right tool stops being a guessing game.

That mindset will outlast every command you memorize today.

🚀 What to Build Next

Reading about Redis only gets you so far. Pick one of these and actually build it:

• 🔗 URL Shortener
• 🛒 Shopping Cart Service
• 🔐 OTP Verification System (you just did this — extend it)
• 🚦 API Rate Limiter
• 🏆 Live Leaderboard
• 💬 Real-Time Chat App

Start with one. Keep it small. The point isn't to build the next unicorn startup — it's to feel why Redis makes these things faster. Do that once, and Redis stops being "another technology to memorize." It becomes a tool you reach for instinctively.

If this helped Redis finally click for you, share it with a developer who's stuck exactly where you were an hour ago. At Elvoret, we write practical, no-fluff guides on backend development, system design, and software engineering — more are coming soon.

Don't just read it. Build it. 🚀