Automatic failover in Redis - Time & Space Complexity
When Redis automatically switches to a backup server after a failure, it needs to check the status of servers and decide quickly.
We want to understand how the time it takes to do this changes as the number of servers grows.
Analyze the time complexity of the following Redis Sentinel automatic failover process.
SENTINEL masters
SENTINEL slaves <master-name>
SENTINEL is-master-down-by-addr <ip> <port> <current-epoch>
SENTINEL failover <master-name>
This sequence checks master and slave servers, detects if the master is down, and triggers failover to a slave.
In this process, the main repeating operations are:
- Primary operation: Checking the status of each slave server for the master.
- How many times: Once for each slave connected to the master.
As the number of slaves increases, the time to check their status grows roughly in a straight line.
| Input Size (number of slaves) | Approx. Operations |
|---|---|
| 10 | 10 status checks |
| 100 | 100 status checks |
| 1000 | 1000 status checks |
Pattern observation: The work grows directly with the number of slaves to check.
Time Complexity: O(n)
This means the time to complete failover checks grows in a straight line as the number of slave servers increases.
[X] Wrong: "Failover time stays the same no matter how many slaves there are."
[OK] Correct: Because Redis must check each slave's status, more slaves mean more checks and more time.
Understanding how failover time grows helps you explain system reliability and scaling in real projects.
"What if Redis used a way to check all slaves at once instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand the concept of failover
Failover means switching to a backup system when the main one stops working.Step 2: Apply this to Redis context
Redis automatic failover switches to a backup Redis server if the main one fails.Final Answer:
To switch to a backup server if the main server fails -> Option CQuick Check:
Automatic failover = switch to backup server [OK]
- Confusing failover with data backup
- Thinking failover speeds up queries
- Mixing failover with encryption
Solution
Step 1: Identify Redis components related to failover
Redis Sentinel is designed to monitor Redis servers and manage failover.Step 2: Confirm other options are unrelated
Redis Cluster manages sharding, Streams handle data streams, Modules add features but don't manage failover.Final Answer:
Redis Sentinel -> Option BQuick Check:
Failover manager = Sentinel [OK]
- Confusing Sentinel with Cluster
- Thinking Streams handle failover
- Assuming Modules manage failover
Solution
Step 1: Understand Sentinel quorum and failover
With multiple Sentinels, they agree on master failure and promote a replica.Step 2: Analyze options
Sentinels do not shut down; clients reconnect after failover; master does not restart automatically.Final Answer:
Sentinels promote one replica to master automatically -> Option AQuick Check:
Master failure triggers replica promotion [OK]
- Thinking Sentinels shut down on failure
- Assuming clients lose connection forever
- Believing master restarts without failover
Solution
Step 1: Understand Sentinel quorum requirement
Sentinel needs multiple instances to agree (quorum) before failover.Step 2: Analyze single Sentinel behavior
With only one Sentinel, no quorum exists, so failover may not trigger reliably.Final Answer:
Failover may not happen due to lack of quorum -> Option AQuick Check:
Single Sentinel lacks quorum for failover [OK]
- Thinking one Sentinel can safely failover
- Believing Sentinel deletes replica data
- Assuming failover is instant without checks
Solution
Step 1: Identify components for high availability
Multiple replicas provide backup data; multiple Sentinels provide reliable failover decisions.Step 2: Evaluate each option
One master, one replica, one Sentinel instance lacks multiple Sentinels; C has multiple masters causing conflicts; D lacks replicas and multiple Sentinels.Final Answer:
One master, multiple replicas, multiple Sentinel instances -> Option DQuick Check:
Replicas + multiple Sentinels = high availability [OK]
- Thinking one Sentinel is enough
- Confusing multiple masters with high availability
- Ignoring replicas in failover setup
Ready to prove it?
Pass the test and this pattern moves unknown
