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.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
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
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
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 ask about
- 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 (L5/E5)
- 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 (L6+/E6+)
- 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.