Redis Sentinel - Monitoring identify master

 

🔥 Redis Sentinel — Ramesh Style

Think of Redis Sentinel as a security guard/manager for Redis.

Its main job is:

"If my Redis master dies, detect it, choose a replica, promote it to master, and tell clients where the new master is."

---

1. Problem without Sentinel

Suppose your architecture is:

Java Application
       |
       ↓
   Redis Master
       |
       ↓
   Redis Replica

Master crashes:

Java Application
       |
       ↓
   ❌ Redis Master
       
Redis Replica
       ↑
     Still alive

But who tells the application:

"Master is dead. Use the replica now."

That's where Sentinel comes in.

---

2. Architecture

Typically:

                    Java Applications
                           |
                           ↓
                    Redis Sentinel
                 /        |        \
                /         |         \
               ↓          ↓          ↓
         Sentinel 1  Sentinel 2  Sentinel 3
                \         |         /
                 \        |        /
                  ↓       ↓       ↓
                 Redis Cluster/Group
                     |
              ┌──────┴──────┐
              ↓             ↓
           Master        Replica
          Redis-A        Redis-B

Actually, Sentinel is a separate monitoring/control layer, not a proxy sitting in the request path.

That's important.

---

3. What does Sentinel do?

Remember these 4 responsibilities:

M → Monitor
E → Election
F → Failover
N → Notify

① Monitor 👀

Sentinel continuously checks Redis nodes.

Sentinel
   |
   ├── Ping Master
   ├── Ping Replica
   └── Ping other Sentinels

Suppose:

Master → ❌

Sentinel detects the failure.

---

4. Subjective vs Objective Down

This is a very important interview topic.

SDown — Subjectively Down

One Sentinel thinks:

"Master is not responding."

That's Subjective Down.

Sentinel 1
    ↓
Master not responding
    ↓
S_DOWN

But we don't immediately fail over.

Why?

Because maybe Sentinel 1 itself has a network problem.

---

ODown — Objectively Down

Multiple Sentinels agree:

Sentinel 1 → Master down
Sentinel 2 → Master down
Sentinel 3 → Master down

Now:

S_DOWN
   +
Quorum agreement
   ↓
O_DOWN

Then failover can begin.

Easy memory:

S = Somebody thinks it's down
O = Others agree it's down

---

5. What happens during Failover?

Suppose:

             Master
            Redis-A
               |
               ↓
            Replica
            Redis-B

Redis-A crashes:

Redis-A ❌

Redis-B ✅

Sentinels detect it.

Then Sentinel starts a leader election among Sentinels.

One Sentinel becomes the coordinator for the failover.

Conceptually:

Sentinel 1
Sentinel 2  → Election → Sentinel 2 becomes leader
Sentinel 3

The elected Sentinel chooses a suitable replica.

Old Master
    ❌

Replica
    ↓
PROMOTE
    ↓
New Master

So:

Before:

Master
  ↓
Replica


After:

Old Master ❌

Replica
   ↓
New Master

---

6. What happens to the Java application?

This is where Sentinel becomes useful for your Spring Boot/Java architecture.

Your application should not hardcode:

redis-master.company.com

as the only source of truth.

Instead, the Redis client can use Sentinel configuration.

Conceptually:

Java Application
       |
       | "Who is current master?"
       ↓
   Sentinel
       |
       ↓
 Redis Master

If failover happens:

Java
 |
 | ask Sentinel
 ↓
Sentinel
 |
 ↓
New Master

The Redis client updates its connection information.

Modern Redis Java clients such as Lettuce support Sentinel-based master discovery/failover.

---

7. Sentinel is NOT Redis Cluster

This is a very common interview question.

Sentinel

Main purpose:

High Availability

Master
   ↓
Replica

Master dies
   ↓
Replica becomes Master

Redis Cluster

Main purpose:

Horizontal scaling + High Availability

Data is distributed across multiple masters using hash slots.

             Redis Cluster

       ┌─────────┐
       │ Master 1│
       └─────────┘
        slots 0-5000

       ┌─────────┐
       │ Master 2│
       └─────────┘
       slots 5001-10000

       ┌─────────┐
       │ Master 3│
       └─────────┘
       slots ...

Each master can have replicas.

Remember:

Sentinel → HA / automatic failover

Cluster → Sharding + HA

---

8. Sentinel does NOT store your Redis data

Very important.

Redis Master
    ↓
Actual data

Sentinel:

Sentinel
    ↓
Monitoring + coordination + failover

Sentinel doesn't act like another Redis database.

---

9. Why 3 Sentinels?

Suppose you have only:

Sentinel 1

It says:

Master is down.

But maybe Sentinel itself has a network problem.

With three:

Sentinel 1 → Down
Sentinel 2 → Down
Sentinel 3 → Down

Now you have stronger agreement.

A common production setup is 3 or 5 Sentinels, depending on availability requirements.

Why odd numbers?

For quorum/majority decisions:

3 → majority = 2
5 → majority = 3

This avoids ties more easily.

---

10. Java/Spring Boot Architecture

Your typical architecture could be:

                 Spring Boot
                     |
              Lettuce/Jedis
                     |
              Redis Sentinel
              /      |      \
             /       |       \
            ↓        ↓        ↓
       Sentinel1 Sentinel2 Sentinel3
                     |
              Redis deployment
                 /        \
                ↓          ↓
             Master      Replica

Application doesn't need to know permanently:

"Redis-B is master"

Sentinel handles master discovery.

---

11. Failure scenario — Interview Favorite ⭐

Interviewer:

"Redis master suddenly goes down. What happens?"

Answer step-by-step:

1. Sentinel monitors Redis nodes
              ↓
2. Sentinel detects master failure
              ↓
3. S_DOWN
              ↓
4. Other Sentinels confirm
              ↓
5. O_DOWN
              ↓
6. Sentinels elect a leader
              ↓
7. Leader selects suitable replica
              ↓
8. Replica is promoted
              ↓
9. New master announced
              ↓
10. Redis clients discover new master

That's the complete flow.

---

🔥 Sentinel vs Cluster — Memorize This

Feature	Sentinel	Redis Cluster
Monitoring	✅	✅
Automatic failover	✅	✅
Replication	Uses Redis replicas	Uses replicas
Sharding	❌	✅
Horizontal data scaling	❌	✅
Multiple masters	❌	✅
Main purpose	HA	Scaling + HA

---

🧠 Ramesh Memory Trick

Think of a company:

Redis Master = CEO
Redis Replica = Deputy CEO
Sentinels = Board members

CEO dies:

CEO ❌
   ↓
Board detects
   ↓
Board agrees
   ↓
Deputy promoted
   ↓
New CEO

That's Redis Sentinel.

One-line interview answer:

"Redis Sentinel is a distributed monitoring and failover mechanism for Redis. It monitors master and replicas, detects failures, reaches quorum, elects a Sentinel leader, promotes an appropriate replica to master, and allows clients to discover the new master."

For your Spring Boot + Redis + Kubernetes architecture, one additional point is important: Sentinel and Kubernetes solve different layers of the problem. Kubernetes can restart/reschedule Redis containers, while Sentinel provides Redis-aware master election and failover.