⚡ Redis Fundamentals

What Is Redis?

Redis (REmote DIctionary Server) is an open-source, in-memory key-value store. That's the whole idea in five words: it keeps its data in RAM and looks it up by key. Because it never has to reach for a spinning disk or even an SSD on the read path, a typical Redis command completes in well under a millisecond — often 50–100× faster than the same lookup against a relational database.

Think of your database as a warehouse: enormous, well-organized, authoritative, but a forklift ride away. Redis is the shelf right next to your desk. You keep the things you reach for constantly on that shelf, and only walk to the warehouse when the shelf doesn't have what you need. The warehouse is still the source of truth — Redis is just the fast copy.

Why "in-memory" matters

RAM is roughly a hundred thousand times faster to read than a disk. By keeping the hot data in memory, Redis turns a database query that might take 30 ms into a cache read that takes 0.3 ms. Multiply that across thousands of requests per second and it is the difference between a snappy app and a crawling one.

Key characteristics

• In-memory storage — data lives in RAM for extremely fast access.
• Rich data structures — not just strings, but hashes, lists, sets, sorted sets, and more.
• Optional persistence — Redis can snapshot to disk (RDB) or append every write to a log (AOF) so data survives a restart.
• Single-threaded & atomic — commands run one at a time, so each individual operation is atomic with no locking needed.
• Time-based expiration — every key can carry a TTL and delete itself automatically.

Installing & Connecting

Before we can store anything, we need a running Redis server and a client library to talk to it from Node.

1. Get a Redis server running

# macOS (Homebrew)
brew install redis
brew services start redis

# Ubuntu / Debian
sudo apt update && sudo apt install redis-server

# Anywhere with Docker (great for local dev)
docker run --name redis -p 6379:6379 -d redis:7

Confirm it's alive with the built-in CLI — it should answer PONG:

redis-cli ping
# PONG

2. Add the client to your Node project

The official client is node-redis. We use v4, which is fully async/await-based — no more callback pyramids.

npm install redis

3. Connect

import { createClient } from 'redis';

// createClient() defaults to redis://localhost:6379
const client = createClient({
  url: process.env.REDIS_URL || 'redis://localhost:6379'
});

// ALWAYS attach an error handler — a dropped connection
// should never crash your whole process.
client.on('error', (err) => console.error('Redis error:', err));

// v4 requires an explicit connect() before any command.
await client.connect();
console.log('Connected to Redis');

The Core Data Types

Redis is often called a "data structure server" because keys don't just hold plain text — they hold structures. Choosing the right one is the single biggest lever on how clean and efficient your code is. Here are the five you'll reach for daily.

Strings — the simplest key-value

A string holds text, a number, or a blob of serialized JSON. It's your default for a plain cached value or a counter.

// Basic set / get
await client.set('greeting', 'Hello, Redis!');
const greeting = await client.get('greeting');   // 'Hello, Redis!'

// Numbers stored as strings can be incremented atomically —
// no read-modify-write race, even with many concurrent requests.
await client.set('page:views', '0');
await client.incr('page:views');                 // 1
await client.incrBy('page:views', 10);           // 11

// Cache a whole object by serializing to JSON:
await client.set('user:1000', JSON.stringify({ name: 'Ada', age: 36 }));
const user = JSON.parse(await client.get('user:1000'));

Hashes — objects without the JSON tax

A hash is a key that maps to a set of field/value pairs — perfect for an object when you want to read or update one field without deserializing the whole thing.

// Store a user profile as a hash
await client.hSet('user:1000', {
  username: 'ada',
  email: 'ada@example.com',
  visits: 10
});

const email = await client.hGet('user:1000', 'email');   // 'ada@example.com'
const all   = await client.hGetAll('user:1000');
// { username: 'ada', email: 'ada@example.com', visits: '10' }

// Increment just one field — no fetch-parse-save round trip
await client.hIncrBy('user:1000', 'visits', 1);          // visits -> 11

Lists — ordered, push and pop from either end

// Track the most recently viewed products (newest first)
await client.lPush('recent:products', 'product:789');
await client.lPush('recent:products', 'product:456');

// Keep only the last 5 by trimming after each push
await client.lTrim('recent:products', 0, 4);

const recent = await client.lRange('recent:products', 0, -1);
// ['product:456', 'product:789']

// Used as a simple queue: lPush to enqueue, rPop to dequeue.

Sets — unique, unordered membership

// Who is currently online? Duplicates are ignored automatically.
await client.sAdd('online:users', 'user:1000');
await client.sAdd('online:users', 'user:1001');
await client.sAdd('online:users', 'user:1000');   // no-op, already present

await client.sIsMember('online:users', 'user:1000');  // true
await client.sCard('online:users');                   // 2  (count)
await client.sMembers('online:users');                // ['user:1000','user:1001']

Sorted sets — sets with a score for ranking

Each member carries a numeric score, and Redis keeps them ordered by it. This is the leaderboard/priority-queue type.

await client.zAdd('leaderboard', [
  { score: 100, value: 'player:1' },
  { score: 75,  value: 'player:2' },
  { score: 150, value: 'player:3' }
]);

// Top 3, highest score first
const top = await client.zRangeWithScores('leaderboard', 0, 2, { REV: true });
// [{ value: 'player:3', score: 150 },
//  { value: 'player:1', score: 100 },
//  { value: 'player:2', score: 75 }]

Expiration & TTL

A cache that never forgets isn't a cache — it's a slowly poisoning copy of stale data. The fix is TTL (Time To Live): tell Redis to auto-delete a key after N seconds, and stale entries clean themselves up.

// Set a value AND its expiry in one command with the EX option (seconds):
await client.set('session:abc', sessionJson, { EX: 1800 }); // gone in 30 min

// PX for millisecond precision:
await client.set('rate:user123', '1', { PX: 60000 });       // gone in 1 min

// Add or change expiry on an existing key:
await client.expire('daily:stats', 3600);                   // 1 hour from now

// How long is left? TTL returns seconds remaining.
await client.ttl('session:abc');   // e.g. 1785
// Special return values:
//   -2  -> the key does not exist
//   -1  -> the key exists but has NO expiry (lives forever)

// Remove an expiry, making a key permanent again:
await client.persist('daily:stats');

TTL is the single most important safety net in caching. Even when you actively delete keys on data changes (next two lessons), a TTL guarantees that any entry you forgot to invalidate can only be wrong for a bounded amount of time.

Your First Cache Lookup

Let's tie it together. The most common caching shape is cache-aside: check Redis first, and only touch the database on a miss — then store the result so the next request is a hit. We'll go deep on this pattern next lesson; here's the shape so the data types feel concrete.

async function getUserById(userId) {
  const cacheKey = `user:${userId}`;

  // 1. Try the cache first
  const cached = await client.get(cacheKey);
  if (cached) {
    console.log('Cache HIT', userId);
    return JSON.parse(cached);
  }

  // 2. Miss — go to the source of truth
  console.log('Cache MISS', userId);
  const user = await db.users.findOne({ _id: userId });

  // 3. Populate the cache for next time (1-hour TTL as a safety net)
  if (user) {
    await client.set(cacheKey, JSON.stringify(user), { EX: 3600 });
  }
  return user;
}

getUserById('1000')  // Cache MISS 1000   (hits the DB, then caches)
getUserById('1000')  // Cache HIT 1000    (served from Redis, ~0.3ms)
getUserById('1000')  // Cache HIT 1000    (still fast until the TTL expires)

That's the entire value proposition: the first request pays the database cost, and every request after it — until the TTL lapses — is answered from memory.

Practice & Quiz

async function recordView(pageId) {
    // TODO: increment `views:${pageId}` and return the new count
}
console.log(await recordView('home'));  // 1
console.log(await recordView('home'));  // 2

async function recordView(pageId) {
    return client.incr(`views:${pageId}`);
}

async function addScore(player, score) {
    await client.zAdd('leaderboard', [{ score, value: player }]);
}

async function topThree() {
    return client.zRangeWithScores('leaderboard', 0, 2, { REV: true });
}

await addScore('ada', 120);
await addScore('grace', 200);
await addScore('linus', 90);
console.log(await topThree());
// [{ value: 'grace', score: 200 },
//  { value: 'ada', score: 120 },
//  { value: 'linus', score: 90 }]

Best Practices & Pitfalls

✅ Do

• Create one client at startup, connect() it, and reuse it — don't open a client per request.
• Use a consistent, colon-namespaced key convention: user:1000, product:42:reviews.
• Set a TTL on cache entries as a safety net, even when you also invalidate them explicitly.
• Match the structure to the data — a hash for objects, a sorted set for rankings.
• Always attach an 'error' handler so a dropped connection can't crash the process.

❌ Don't

• Run KEYS * in production — it scans every key and blocks the single-threaded server. Use SCAN instead.
• Store giant blobs (multi-megabyte values); large keys hurt latency for everyone.
• Cache data that must be perfectly consistent (like an account balance mid-transaction) without a clear invalidation plan.
• Forget to await — every v4 command is a Promise.

// ❌ Blocks Redis while it walks the entire keyspace
const keys = await client.keys('user:*');

// ✅ SCAN iterates in small, non-blocking chunks
for await (const key of client.scanIterator({ MATCH: 'user:*', COUNT: 100 })) {
    console.log(key);
}

Summary

📚 Additional Resources

• redis.io — Understand Redis data types
• node-redis — official Node.js client (GitHub)
• redis.io — EXPIRE command reference

🚀 What's Next?

You can now store and expire data in Redis. Next we turn that into a discipline: Caching Patterns & Best Practices — cache-aside, read-through, write-through, write-behind, and how to survive a thundering herd.