Leader Election Patterns
Explore how Redis can be used to facilitate leader election in distributed services for high availability.
Leader Election Patterns is a free Redis Caching & Messaging (Pub/Sub, Streams) lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Redis Caching & Messaging (Pub/Sub, Streams) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Leader Election?
In a distributed system, multiple instances of your application run simultaneously. Sometimes, you need one instance to perform a specific task, like processing a queue or coordinating updates, to avoid conflicts or duplicate work.
This is where leader election comes in. It's a process where distributed nodes agree on a single node to be the "leader" at any given time.
Redis for Election Coordination
Redis is an excellent choice for implementing leader election due to its speed, atomic operations, and strong consistency guarantees for single-key operations.
- Atomic Operations: Commands like
SETNXorSET ... NX EXexecute entirely or not at all, preventing race conditions. - Persistence: If configured, Redis can persist data, making leader election state more durable.
- Centralized State: Provides a single, agreed-upon source of truth for who the current leader is.
Basic Election: SETNX
The simplest way to attempt leader election with Redis is using the SETNX command. SETNX key value ("Set if Not eXists") sets a key only if it doesn't already exist. If the key is set, it returns 1; otherwise, 0.
The first process to successfully set the leader key becomes the leader.
import redis
import time
# Connect to Redis
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v1"
MY_ID = "process_A" # Unique ID for this process
print(f"Process {MY_ID} attempting to become leader...")
# Try to acquire leadership
if r.setnx(LEADER_KEY, MY_ID):
print(f"Process {MY_ID} is now the leader!")
# Simulate leader work
time.sleep(3) # Work for 3 seconds
# In a real scenario, the leader would perform tasks
# and eventually release leadership or renew its lease.
r.delete(LEADER_KEY) # Release leadership
print(f"Process {MY_ID} released leadership.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")The Problem: Leader Failure
Consider the basic SETNX approach. What if the elected leader (process_A from the last example) crashes immediately after setting the LEADER_KEY, but before it has a chance to delete it?
The LEADER_KEY would remain in Redis indefinitely, preventing any other process from becoming leader. This creates a permanent deadlock, breaking your distributed system's high availability.
TTL for Fault Tolerance
To prevent deadlocks, we must add an expiration time (Time-To-Live, or TTL) to the leader key. This ensures that even if a leader crashes, its leadership key will eventually expire, allowing a new election.
We can use the EXPIRE key seconds command right after SETNX to set a TTL.
import redis
import time
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v2"
MY_ID = "process_B"
LOCK_TTL = 10 # seconds
print(f"Process {MY_ID} attempting to become leader...")
if r.setnx(LEADER_KEY, MY_ID):
r.expire(LEADER_KEY, LOCK_TTL) # Set expiration
print(f"Process {MY_ID} is now the leader with TTL {LOCK_TTL}s!")
# Simulate leader work for a short period
time.sleep(LOCK_TTL // 2)
print(f"Process {MY_ID} completed its short task.")
if r.get(LEADER_KEY) == MY_ID: # Check if still leader before deleting
r.delete(LEADER_KEY)
print(f"Process {MY_ID} released leadership.")
else:
print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")The SETNX + EXPIRE Race
While adding EXPIRE is better, a critical race condition still exists! Imagine this sequence:
- Process A calls
SETNX LEADER_KEY process_A. It succeeds (returns1). - Process A then crashes before it can call
EXPIRE LEADER_KEY 10.
The LEADER_KEY is set, but without a TTL, leading to the same deadlock situation as before. We need an atomic way to set the key and its expiration.
Atomic SET for Robustness
Redis provides a powerful, atomic SET command that combines setting a key's value and its expiration. The format is SET key value [EX seconds | PX milliseconds] [NX | XX].
NX: Only set the key if it does not already exist (likeSETNX).EX seconds: Set an expiration time in seconds.PX milliseconds: Set an expiration time in milliseconds.
Using SET LEADER_KEY MY_ID NX EX 10 ensures that both conditions (key not existing AND expiration) are applied atomically.
import redis
import time
r = redis.Redis(decode_responses=True)
LEADER_KEY = "my_app:leader_v3"
MY_ID = "process_C"
LOCK_TTL = 10 # seconds
print(f"Process {MY_ID} attempting to become leader atomically...")
# Try to acquire leadership using atomic SET with NX and EX
# This command returns True if the key was set, False otherwise.
if r.set(LEADER_KEY, MY_ID, nx=True, ex=LOCK_TTL):
print(f"Process {MY_ID} is now the leader with atomic TTL {LOCK_TTL}s!")
# Simulate leader work
time.sleep(LOCK_TTL // 2)
print(f"Process {MY_ID} still working as leader.")
if r.get(LEADER_KEY) == MY_ID: # Important: check value before deleting!
r.delete(LEADER_KEY)
print(f"Process {MY_ID} gracefully released leadership.")
else:
print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
current_leader = r.get(LEADER_KEY)
print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")Maintaining Leadership: Heartbeats
Once a leader is elected using the atomic SET command, it needs to periodically signal that it's still alive and capable of leading. This is done through "heartbeats."
A heartbeat involves the leader refreshing the expiration time of its leadership key before it expires (e.g., using EXPIRE LEADER_KEY NEW_TTL or PEXPIRE). If the leader fails to send heartbeats, its key will expire, triggering a new election among the remaining processes.
Check Your Understanding
Which of the following are benefits of using the atomic SET key value NX EX seconds command for leader election compared to separate SETNX and EXPIRE commands?
Recap: Leader Election
We've explored how Redis can facilitate leader election in distributed systems. We started with basic SETNX, identified its pitfalls, and learned to improve it with EXPIRE.
Crucially, we discovered the robust and atomic SET key value NX EX seconds command to prevent race conditions and ensure keys always have an expiration. Finally, we touched upon the importance of leader heartbeats to maintain active leadership.
Frequently asked questions
Is the “Leader Election Patterns” lesson free?
Yes — the full text of “Leader Election Patterns” is free to read here on the web, and the Redis Caching & Messaging (Pub/Sub, Streams) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Redis Caching & Messaging (Pub/Sub, Streams) course, upgrade to CoddyKit PRO.
What will I learn in “Leader Election Patterns”?
Explore how Redis can be used to facilitate leader election in distributed services for high availability. You practise Redis Caching & Messaging (Pub/Sub, Streams) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Redis Caching & Messaging (Pub/Sub, Streams)?
No prior experience is required. Redis Caching & Messaging (Pub/Sub, Streams) on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Leader Election Patterns” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Redis Caching & Messaging (Pub/Sub, Streams) lesson?
Yes. Every Redis Caching & Messaging (Pub/Sub, Streams) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Distributed Locks with Redis
- Leader Election Patterns
- Redis as a Coordination Service
- Distributed Rate Limiting