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.