Design Leader Election

"Design leader election" is a small prompt with a sharp safety edge. You run several identical copies of a service for availability, and some piece of work must be done by exactly one of them at any moment. There is almost no architecture to draw. There is a pool of interchangeable instances, one job that must not run twice, and a shared place to record who currently owns it. Instances crash, stall, and get cut off by the network. Through all of that, the system must never let two of them believe they are the leader at once. Get that one property right and the design is done. Get it wrong and you have two schedulers firing the same billing job or two coordinators handing out the same shard.

This is a senior backend shape, and it is a pure test of distributed-systems judgment. The prompt forces every coordination instinct to show up honestly. There is shared mutable state, the record of who leads, so you have to say where it lives and how a write to it is made atomic. There is failure, because the leader will die mid-term, so you have to detect that without a human watching and hand the role to someone else. There is the classic bug: the old leader that comes back thinking it is still in charge. You have to know what a fencing token is and why a timeout alone does not save you. And there is the partition question, because when the network splits you must choose safety over availability or accept split-brain. A candidate who reasons through all of that reads as someone who has run real distributed services. One who says "just use a flag in the database" and stops has not.

The Discord angle

Discord runs many stateful real-time services where a job has to run on exactly one instance, so this lands as a senior design and coding prompt. Reported loops describe it plainly: implement leader election with Redis leases so exactly one instance is active, with a follow-up that swaps the lease store for etcd. The setting is concrete.