Redis

Backend Fundamentals · Caching · 8 min read

1. What problem does this solve?

If you skip Redis, you’ll either:

• Hit your primary database for every request → higher latency, higher cost.
• Build custom in‑process caches that don’t survive restarts or scale.
• Use a heavier message broker for simple key/value needs.

Redis is the go‑to solution for these patterns in modern backend stacks.

2. Mental model

Analogy

Think of Redis as a super‑fast pantry in a kitchen.

• The pantry is in the same room as the chef (your app), so the chef can grab ingredients instantly.
• It holds only the most frequently used items (cache).
• If the pantry runs out of space, the chef can decide to throw out the least used items (eviction).
• The pantry can also keep a small inventory list (data structures) so the chef knows what’s inside without opening each shelf.

Engineering model

• In‑memory key/value store – all data lives in RAM for sub‑millisecond access.
• Single‑threaded event loop – commands are processed sequentially, eliminating locks.
• Persistence options – optional snapshots (RDB) or append‑only logs (AOF) for durability.
• Replication & clustering – for high availability and horizontal scaling.
• Rich data types – strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, streams.

3. Deep explanation

Internals

• Memory layout – Redis stores data in a compact, contiguous memory space.
  • Strings: raw bytes.
  • Hashes: ziplist or hashtable depending on size.
  • Lists: linked list or ziplist.
  • Sets: hashtable or intset.
  • Sorted sets: skiplist + hashtable.
• Event loop – single thread processes commands one at a time, using select/epoll for I/O.
• Persistence
  • RDB – point‑in‑time snapshot every N seconds.
  • AOF – append‑only file, rewrites periodically.
• Replication – master‑slave replication via asynchronous replication stream.
• Cluster – 16‑slot hash space, each node owns a subset; supports automatic rebalancing.

Important terminology

Trade‑offs

Failure modes

• Memory exhaustion → OOM, eviction, or crash.
• Network partition → stale replicas, split brain.
• Disk failure (when using persistence) → data loss.
• Blocking commands (BLPOP, BRPOP, WAIT) can stall the single thread.

Limitations

• Not a relational DB – no joins, ACID transactions.
• Limited query language – only key‑based lookups or data‑type specific commands.
• Data size limited by RAM; large datasets require sharding or external storage.

Where it fits

[Client] → [API Gateway] → [Microservice] → [Redis Cache] → [PostgreSQL]

• Cache layer between service and DB.
• Session store for stateless services.
• Pub/Sub for event delivery.
• Rate limiter, job queue, leaderboard, etc.

Interaction with related concepts

• Load balancer – can route traffic to Redis cluster nodes.
• CDN – can cache Redis‑served data at edge.
• Database – Redis often sits in front of a relational or document DB.
• Message broker – Redis Pub/Sub is lighter weight than Kafka for simple events.

4. How it works

Cache hit/miss flow

sequenceDiagram
    participant App as Node.js App
    participant Redis as Redis Server
    participant DB as PostgreSQL

    App->>Redis: GET user:123
    alt Cache hit
        Redis-->>App: user data
    else Cache miss
        App->>DB: SELECT * FROM users WHERE id=123
        DB-->>App: user data
        App->>Redis: SET user:123 <data> EX 3600
        Redis-->>App: OK
    end

Rate limiter using sorted set

sequenceDiagram
    participant Client
    participant App
    participant Redis

    Client->>App: POST /api/action
    App->>Redis: ZADD user:123:actions <timestamp> <timestamp>
    App->>Redis: ZREMRANGEBYSCORE user:123:actions 0 <now-1h>
    App->>Redis: ZCARD user:123:actions
    alt > limit
        App-->>Client: 429 Too Many Requests
    else
        App-->>Client: 200 OK
    end

5. Practical implementation

TypeScript example – caching a DB query

// src/cache.ts
import { createClient } from 'redis';
import { Pool } from 'pg';

const redis = createClient({
  url: process.env.REDIS_URL,
});
redis.on('error', err => console.error('Redis error', err));
await redis.connect();

const pgPool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

/**
 * Fetch user by id, cache result for 5 minutes.
 */
export async function getUser(id: string) {
  const cacheKey = `user:${id}`;

  // 1️⃣ Try cache first
  const cached = await redis.get(cacheKey);
  if (cached) {
    console.log('Cache hit');
    return JSON.parse(cached);
  }

  // 2️⃣ Cache miss – query DB
  const res = await pgPool.query('SELECT * FROM users WHERE id = $1', [id]);
  const user = res.rows[0];
  if (!user) throw new Error('Not found');

  // 3️⃣ Store in Redis with TTL
  await redis.set(cacheKey, JSON.stringify(user), {
    EX: 300, // 5 minutes
  });

  console.log('Cache miss, stored');
  return user;
}

Using Redis data structures – leaderboard

// src/leaderboard.ts
import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

/**
 * Add score to user in leaderboard.
 */
export async function addScore(userId: string, score: number) {
  await redis.zAdd('leaderboard', { score, value: userId });
}

/**
 * Get top N users.
 */
export async function top(n: number) {
  return await redis.zRangeWithScores('leaderboard', 0, n - 1, { REV: true });
}

6. Production considerations

7. Common mistakes

8. Senior engineer perspective

Design decisions at scale

Bottlenecks

• Memory pressure – OOM or eviction.
• Single‑threaded command processing – heavy Lua or blocking ops.
• Network latency – cross‑region traffic.

Failure scenarios

• Network partition – stale replicas, split brain.
• Master crash – failover delay, data loss if noeviction.
• Disk failure – AOF corruption.

When NOT to use

• Need ACID transactions or complex joins.
• Persistently large datasets (> RAM).
• Long‑term archival storage.
• Strict durability without persistence.

9. Interview questions

10. Hands‑on task

Implement a per‑user rate limiter using Redis sorted sets in a Node.js project.

1. Create an endpoint /api/action that accepts a user ID.
2. Store each request timestamp in a sorted set rate:user:<id>.
3. Keep only the last 60 seconds of timestamps.
4. If the count exceeds 10 requests, return 429.
5. Use node-redis and TypeScript.
6. Write unit tests that simulate rapid requests and verify the limiter.

11. Quick revision

• Redis is an in‑memory key/value store with rich data types.
• Single‑threaded event loop → no locks, but blocking ops stall all commands.
• Persistence: RDB snapshots + AOF logs.
• Replication: master‑slave (Sentinel) or sharding (Cluster).
• Eviction policies control memory usage (noeviction, allkeys-lru, etc.).
• Common use cases: cache, session store, pub/sub, rate limiting, leaderboards.
• Watch for memory exhaustion, blocking commands, and missing TTLs.
• Use connection pooling and retry logic.
• Monitor memory, latency, replication lag, and slowlog.
• Avoid using Redis as a primary relational DB.
• For scale: choose cluster vs sentinel, set proper eviction, enable persistence, and secure connections.

12. References

• https://redis.io/docs/
• https://redis.io/docs/manual/persistence/
• https://redis.io/docs/manual/cluster/
• https://redis.io/docs/manual/sentinel/
• https://github.com/redis/node-redis
• https://github.com/luin/ioredis
• https://redis.io/docs/reference/commands/
• https://redis.io/docs/management/monitoring/
• https://redis.io/docs/management/security/
• https://redis.io/docs/management/backup/