# Design a distributed leader election service: system design interview question

> Per-group leader authority under process pauses, network failures, and delayed writes from former leaders.

Source: https://sysround.com/questions/design-distributed-leader-election-service
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a service that selects one active leader for each resource group and replaces failed leaders. Prevent former leaders from committing protected operations after a replacement becomes active."

## What to clarify first

- Scale
- Read and write mix
- Lease timing
- Latency
- Safety boundary
- Consistency and availability
- Durability
- Deployment and failures
- Protected operations
- Scope limits

## Scope of a strong answer

Core requirements:

- Grant one current lease for each resource group.
- Renew and release leases.
- Replace leaders after failure or lease expiry.
- Reject protected commits from former leaders after replacement activation.

Usually out of scope:

- Build a consensus protocol from first principles.
- Assign application tasks to leaders.
- Enforce strict fairness or candidate priorities.
- Protect external effects that cannot check leader authority.

## What interviewers probe

### Leader changes during network failures

A timeout cannot distinguish a failed leader from a slow leader. Different candidates can each believe they hold authority.

### Former leaders and protected writes

A former leader can resume or send delayed writes. Its unfinished transactions can also delay a replacement beyond the recovery target.

### Retries and recovery

Retries can repeat old requests. Snapshot recovery can erase grants whose tokens never reached a protected store.

## Common mistakes

- The design treats a single elected leader as proof that all former leaders stopped.
- The design checks authority before a transaction but does not protect the commit.
- The design activates a replacement before the store rejects earlier leaders.
- The design uses client timeouts while old transactions can hold locks without a store deadline.
- The design reconstructs token history from store guards that omit issued but uninstalled tokens.
- The design sends every protected write through the election service without a capacity reason.

## The bar by level

- **Senior:** Defines majority authority and ordered fencing tokens. Makes activation safe against unfinished writes. Meets the replacement target with store deadlines and handles delayed requests.
- **Staff+:** Defines safety across authority and storage failures. Preserves every issued epoch through recovery, including uninstalled grants. Explains activation limits across multiple stores, regions, and external effects.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=leader-election


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.