Leader/Follower via Redis (Lease-Based Leader Election)
You have N stateless service instances running the same job. At any time, exactly one instance should act as the leader (performing a singleton task), and the rest should be followers/standby.
You are allowed to use Redis as a coordination dependency (single primary Redis endpoint is fine for the interview). You may use any Redis features you want (e.g., SET NX PX, Lua scripts, Pub/Sub).
Requirements
-
Leader election:
at most one leader at a time.
-
Failover:
if the leader crashes or becomes unhealthy, a new leader should be elected within a bounded time.
-
Lease/heartbeat:
leadership should be time-bounded and renewed.
-
Correctness concerns:
discuss how you avoid or mitigate:
-
split brain
-
leader “sticking” after a crash
-
clock skew assumptions
-
network hiccups / GC pauses
-
Operational concerns:
metrics/logging you’d add, and what happens if Redis is unavailable.
Deliverables
-
A clear algorithm/protocol description.
-
Key Redis data model (keys, TTLs, values).
-
Edge cases and how the system behaves.