# Leader Election & Idempotency — System Design

Source: https://www.geekswithgeeks.com/en/system-design/sd-consensus-idempotency

> Agreeing on one truth among many nodes, and surviving retries safely.

## Why you need a leader

Some decisions (who accepts writes, who assigns work) need exactly one node in charge at a time. **Leader election** lets a cluster agree on that node and detect when it needs replacing.

## Raft, briefly

**Raft** is a consensus algorithm where nodes vote for a leader using randomized timeouts; the candidate with the most votes wins a term. The leader replicates a log to followers, and an entry is only considered committed once a **majority** has it — this survives any minority of node failures.

## Idempotency saves you

A network timeout doesn't tell you if the request landed. If retries and duplicate delivery are inevitable, make operations **idempotent**: a client-generated `idempotency key` lets the server recognize and safely ignore a repeat of the same logical request.

**Quiz:** In Raft, when is a log entry considered committed?

- [ ] As soon as the leader writes it
- [x] Once a majority of nodes have replicated it
- [ ] Once every node has replicated it

*Answer:* Once a majority of nodes have replicated it. Majority (quorum) commitment lets Raft tolerate a minority of node failures while staying correct.