Design leader election using Redis leases

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.