What Interviewers Really Ask About Redis: Top Questions Covered

Nowadays, Redis is one of the most commonly used technologies in modern backend systems, and questions about Redis are almost guaranteed to come up in backend or full-stack developer interviews.

Whether you’re a fresher preparing for your first interview or an experienced engineer looking for a new opportunity, having a solid understanding of Redis concepts is essential.

In this article, we’ll explore the most frequently asked Redis interview questions, along with clear explanations and practical insights to help you confidently answer them in your next interview.

1. What is Redis?

Answer:
Redis (Remote Dictionary Server) is an in-memory key-value data store used as a database, cache, message broker, and queue. Since data is stored in memory, Redis provides very low latency and high throughput.

Use Cases:

• Caching API responses
• Session storage
• Rate limiting
• Real-time chat
• Pub/Sub messaging
• Leaderboards

2. Why use Redis instead of MongoDB for caching?

Answer:
The table below highlights the key use cases for Redis over MongoDB.

3. How do you invalidate cache?

Answer:

From an interview perspective, when someone asks “How do you invalidate cache in Redis?”, they’re usually testing whether you understand cache consistency strategies or not.

A strong answer would cover multiple approaches:

i. Time based expiration (TTL) method:

TTL defines how long a key remains in Redis before it is automatically deleted, and for data that changes frequently, it is generally better to use a shorter TTL to keep the cached data up to date.

SET user:123 "{...}" EX 3600

ii.Cache-Aside (Lazy Invalidation):

In this method while any change in DB happens then we immediately delete the respective cache.

updateUserInDB(user);
redis.del("user:123");

Interview point: Most commonly used pattern in distributed systems.

iii. Write-Through Cache:
In this technique if any update of the DB comes then before making the update in DB, we first make the change in respective cache key.

Application
↓
Redis
↓
Database

Interview point:

• Cache always remains fresh.
• Higher write latency.

iv. Event-Driven Invalidation

Publish an event whenever data changes.

DB Update
    ↓
 Kafka Event
    ↓
 Cache Invalidation Service
    ↓
 Redis DEL

Interview point: Common in microservices architectures.

4. What Redis data structures have you used?
Answer:

For an interview, don’t just list Redis data structures. Explain what they are and where you’ve used them.

Get Mohd Akib’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

A strong answer could be:

I’ve worked with several Redis data structures depending on the use case:

• Hashes — Used when I need to store structured objects with multiple fields, such as user details (name, email, status) and update individual fields without rewriting the entire object.
• Lists — Used for simple queues and task processing where items are pushed and consumed in order.
• Sets — Used for storing unique values, such as user IDs who liked a post, tags, or permissions. Redis provides efficient membership checks.
• Sorted Sets (ZSETs) — Used for leaderboards, ranking systems, and priority-based processing where each member has a score.
• Strings — Most commonly used for caching objects, session data, user profiles, and counters. For example, storing serialized user information with a TTL.

5. A probable follow-up question to the above topic is: “What is the difference between Strings and Hashes in Redis?”
Answer:
A Redis String stores data as a single value, whereas a Redis Hash stores data as field-value pairs. Hashes are better suited for structured data because individual fields can be updated or retrieved without modifying the entire object.

Example: Using String

Store the entire user object as JSON:

SET user:101 '{"name":"John","email":"john@test.com","age":25}'

Example: Using Hash

HSET user:101 name John email john@test.com age 25

6. How have you used Redis for session management?
Answer:
Approach for above question can goes like below:

The Problem

Initially, session data was stored in the application’s local memory.

User → Load Balancer → App Server 1

If there is single server then no issue will occur but due to scaling if number of server are increased in that case it will be problem.

Request 1 → Server 1
Request 2 → Server 2

Server 2 might have no knowledge of the user’s session, causing authentication failures.

Their comes the redis:
Since the redis is centralized and every server shares the same redis.

And hence this eliminates the need for sticky session.

7. What is a Redis Queue?

Answer:(in nodejs perspective)

i. BullMQ

Built on Redis and supports:

• Delayed jobs
• Retries
• Rate limiting
• Job priorities
• Repeatable jobs
• Multiple workers

How Redis Helps

Redis stores queue data structures internally.

For example, a job might look like:

{
  "id": 123,
  "type": "sendEmail",
  "data": {
    "to": "user@example.com"
  }
}

Workers continuously poll Redis and fetch available jobs.
Without Queue

app.post('/signup', async (req, res) => {
  await sendWelcomeEmail(); // takes few seconds

  res.send('Done');
});

With Queue

app.post('/signup', async (req, res) => {
  await emailQueue.add('sendEmail', {
    to: req.body.email,
  });

  res.send('Email scheduled');
});