If you're preparing for a Node.js backend interview, Redis is one of those technologies you should understand beyond just knowing that it's "fast."

Redis is commonly used for caching, sessions, rate limiting, counters, Pub/Sub, distributed coordination, and fast data access.

In this article, I'll cover the Redis concepts that are especially important for backend development and interviews.

🚀 What is Redis?

Redis is an in-memory data store that provides several useful data structures and very fast operations.

Instead of primarily reading every value from disk like a traditional relational database, Redis keeps its working dataset in memory.

A common backend architecture looks like:

Client
   ↓
Node.js / Express API
   ↓
Redis
   ↓
Database

Redis can reduce the number of requests that reach the primary database.

⚡ Why is Redis so fast?

The major reason is that Redis is designed around in-memory data access.

Instead of:

Application → Disk-based Database → Response

we can have:

Application → Redis RAM → Response

This makes Redis especially useful when the same data is requested repeatedly.

📦 Redis Data Types

Redis isn't limited to simple key-value strings.

Some important data types are:

String

SET user:1:name "Krati"
GET user:1:name

Hash

HSET user:1 name "Krati" role "Backend Developer"

Hashes are useful when storing multiple fields belonging to an object.

Set

SADD online_users 101
SADD online_users 102

Sets automatically maintain uniqueness.

Sorted Set

ZADD leaderboard 1000 user101
ZADD leaderboard 1500 user102

Useful for rankings and leaderboards.

⏳ TTL — Time To Live

When Redis is used as a cache, we usually don't want data to remain forever.

We can set an expiration time:

SET user:1 "some-data" EX 300

The key expires after 300 seconds.

Check the remaining time:

TTL user:1

TTL is important because it helps:

• Remove old cache data
• Control memory usage
• Reduce stale data
• Automatically clean temporary values

🧠 Cache-Aside Pattern

This is one of the most important Redis concepts for backend interviews.

Suppose we have:

GET /users/101

Instead of querying the database every time:

Request
   ↓
Database
   ↓
Response

we use Redis.

Request
   ↓
Redis
   ↓
Cache HIT → Return data

If Redis doesn't contain the data:

Request
   ↓
Redis
   ↓
CACHE MISS
   ↓
Database
   ↓
Store result in Redis
   ↓
Return response

This is called the Cache-Aside pattern.

The application is responsible for reading and populating the cache.

🎯 Cache Hit vs Cache Miss

Cache Hit

The requested data exists in Redis.

Request
 ↓
Redis
 ↓
HIT
 ↓
Return

The database doesn't need to be queried.

Cache Miss

The requested data isn't present.

Request
 ↓
Redis
 ↓
MISS
 ↓
Database
 ↓
Redis SET
 ↓
Return

A useful metric is:

Cache Hit Ratio =
Cache Hits / (Cache Hits + Cache Misses)

🗑️ Cache Invalidation

One of the hardest problems with caching is keeping cached data consistent with the database.

Suppose:

Database:
User name = Alice

Redis:
User name = Alice

Now the user changes their name:

Database:
Alice → Bob

But Redis still contains:

Alice

Now we have stale cache data.

A common solution is:

UPDATE Database
       ↓
DELETE Redis key

For example:

await db.user.update({
  where: { id },
  data: updateData
});

await redis.del(`user:${id}`);

The next request will cause a cache miss and fetch the latest data from the database.

🟢 Using Redis with Node.js

The official Node.js Redis client is node-redis.

Basic setup:

import { createClient } from "redis";

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

redis.on("error", (err) => {
  console.error("Redis error:", err);
});

await redis.connect();

Set a value:

await redis.set("name", "Krati");

Get it:

const name = await redis.get("name");

Set with TTL:

await redis.set("otp:123", "456789", {
  EX: 300
});

Delete:

await redis.del("otp:123");

🚦 Redis for Rate Limiting

Redis is also very useful for implementing API rate limiting.

Imagine:

POST /login

We want to allow only:

5 attempts / minute

We can maintain a counter in Redis.

Conceptually:

Request
   ↓
Redis INCR
   ↓
Check count
   ↓
Limit exceeded?
   ├── YES → Reject
   └── NO  → Continue

Example:

INCR login:user123
EXPIRE login:user123 60

Redis works well here because operations such as INCR are atomic.

It's also shared across multiple Node.js instances:

             ┌── Node Server 1
Client ──────┼── Node Server 2
             └── Node Server 3
                    ↓
                  Redis

All servers can use the same rate-limit state.

🔐 Redis for Sessions

When an application has multiple servers, storing sessions only in one server's memory can become problematic.

Instead:

                ┌── Server 1
Client ─────────┼── Server 2
                └── Server 3
                       ↓
                     Redis

All servers can access the same session information.

Redis documentation specifically describes Redis as a useful shared session store for stateless application servers.

🔄 Atomic Operations

An operation is atomic when it executes as one indivisible operation from the perspective of other Redis commands.

For example:

INCR counter

Instead of doing:

GET counter
   ↓
counter + 1
   ↓
SET counter

we can use:

INCR counter

This is especially useful for:

• Counters
• Rate limiting
• Concurrent requests
• Distributed applications

📢 Redis Pub/Sub

Redis can also provide a publish/subscribe mechanism.

Architecture:

Publisher
    ↓
Redis Channel
    ↓
Subscribers

Example:

PUBLISH notifications "Order created"

Another service can subscribe:

SUBSCRIBE notifications

Useful for:

• Notifications
• Real-time events
• Lightweight service communication

Important interview point

Redis Pub/Sub is not a durable message queue.

If a subscriber is disconnected, it can miss messages.

For durable event processing, Redis Streams are a better concept to study. Redis Streams support persisted entries and consumer groups.

💾 Redis Persistence: RDB vs AOF

Redis is primarily memory-based, but it supports persistence.

Two important mechanisms are:

RDB

RDB = Redis Database snapshot

Redis periodically creates a point-in-time snapshot of the dataset.

Redis
  ↓
Snapshot
  ↓
Disk

Advantages:

• Compact
• Good for backups
• Efficient snapshot-based recovery

Disadvantage:

• Changes made after the latest snapshot may be lost after a failure.

AOF

AOF = Append Only File

Instead of only taking periodic snapshots, Redis records write operations in an append-only log.

SET user:1 Alice
INCR counter
DEL user:2
        ↓
       AOF
        ↓
       Disk

When Redis restarts, the recorded operations can be replayed to reconstruct the dataset.

AOF durability depends on its fsync configuration; stronger durability generally comes with more I/O cost.

Quick comparison

🧹 Redis Eviction

Redis data lives primarily in memory, so memory management is important.

If Redis reaches its configured memory limit, an eviction policy can determine what happens to keys.

Some policies include:

noeviction
allkeys-lru
volatile-lru
allkeys-lfu

Interview question:

What happens when Redis memory is full?

Answer:

Redis applies the configured memory policy. Depending on the policy, it may evict eligible keys or reject writes.

💥 Cache Stampede

Consider a popular API:

1000 requests
      ↓
Same cached key
      ↓
Cache expires
      ↓
1000 CACHE MISS
      ↓
1000 Database queries

The database can suddenly become overloaded.

This is called a cache stampede.

Possible solutions:

• Distributed locking
• Request coalescing
• Background refresh
• TTL jitter
• Cache warming

🔒 Redis Distributed Lock

Redis can also be used for distributed coordination.

A basic locking concept is:

SET lock:payment 123 NX EX 30

Here:

• NX → set only if the key doesn't exist
• EX 30 → lock expires after 30 seconds

This can help ensure that multiple application instances don't simultaneously perform the same critical operation.

For production-grade distributed locking, however, you need to consider ownership, expiry, failures, and Redis topology rather than treating a single command as a complete locking solution.

🏗️ Redis in a Real Node.js Architecture

A typical backend might look like:

                     ┌──────────────┐
                     │   Client     │
                     └──────┬───────┘
                            ↓
                     ┌──────────────┐
                     │ Load Balancer│
                     └──────┬───────┘
                            ↓
                ┌───────────┴───────────┐
                ↓                       ↓
         Node.js Server 1       Node.js Server 2
                │                       │
                └───────────┬───────────┘
                            ↓
                         Redis
                            ↓
                         Database

Redis can handle:

• Frequently accessed data
• Sessions
• Rate-limit counters
• Temporary tokens
• Distributed coordination
• Real-time messaging

while the database remains the primary source of durable business data in many architectures.

🎯 Redis Interview Cheat Sheet

Before a Node.js backend interview, remember:

Redis
 ↓
In-memory data store
 ↓
Fast
 ↓
Cache
 ↓
TTL
 ↓
Cache Hit / Miss
 ↓
Cache-Aside
 ↓
Cache Invalidation
 ↓
Rate Limiting
 ↓
Sessions
 ↓
Atomic Operations
 ↓
Pub/Sub
 ↓
Streams
 ↓
RDB / AOF
 ↓
Eviction
 ↓
Cache Stampede
 ↓
Distributed Lock

Questions you should be able to answer

1. Why is Redis fast?

Because it is designed around in-memory data access and efficient data structures.

2. Redis vs PostgreSQL?

Redis is commonly used for fast access, caching, sessions and transient/shared state; PostgreSQL is generally used for durable relational business data.

3. What is Cache-Aside?

Application checks Redis → on miss queries DB → stores result in Redis → returns response.

4. How do you handle stale cache?

Invalidate or update the cache when the underlying database data changes.

5. Why Redis for rate limiting?

Fast shared storage plus atomic operations such as INCR.

6. RDB vs AOF?

RDB = snapshots.
AOF = append-only write log.

7. What happens if Redis goes down?

For cache use cases, the application should ideally fall back to the database where appropriate, with proper timeouts, error handling and monitoring.

💡 Final Takeaway

Redis isn't just a "cache."

For a backend developer, think of Redis as a high-speed shared data layer that can solve several problems:

Caching       → Reduce DB load
TTL           → Automatically expire data
Rate limiting → Control requests
Sessions      → Share session state
Counters      → Atomic increments
Pub/Sub       → Lightweight messaging
Streams       → Durable event processing
Locks         → Distributed coordination
Persistence   → RDB / AOF

If you're preparing for a 2+ YOE Node.js interview, focus less on memorizing commands and more on being able to explain why Redis is used, where it fits in the architecture, cache invalidation, failure scenarios, and the trade-offs involved.

📚 Further Reading

• Redis Documentation: https://redis.io/docs/latest/
• Redis Session Store: https://redis.io/docs/latest/develop/use-cases/session-store/
• Redis Streams: https://redis.io/docs/latest/develop/data-types/streams/
• Redis Distributed Locks: https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/

nodejs #redis #backend #javascript #webdevelopment #systemdesign #interview

Full CheatSheet