Multi-Paxos & Zab

Beyond single-decree Paxos

Classic Paxos decides one value. Real systems need a log of operations — Multi-Paxos runs Paxos repeatedly with a stable leader to amortize prepare phases.

Mental model:

1. Leader election — one proposer dominates a term/epoch
2. Log slots — each index decided via Paxos (or fast path under leader)
3. Learners apply committed entries in order

Raft is an equivalent, more teachable decomposition of the same problem space.

Paxos phases (awareness)

• Phase 1 (Prepare) — proposer picks ballot number, gets promises
• Phase 2 (Accept) — proposer sends value; acceptors ack if ballot is highest seen

Multi-Paxos optimization: skip Phase 1 while leader is stable.

Zab (ZooKeeper Atomic Broadcast)

ZooKeeper uses Zab, not Raft — primary-order broadcast for a replicated log:

• Discovery — elect primary, epoch bump
• Synchronization — followers catch up to primary's history
• Broadcast — primary orders and replicates state changes

Kafka older controller and many metadata systems used ZK; KRaft replaces ZK with internal Raft.

When interviewers ask "Paxos vs Raft"

	Paxos / Multi-Paxos	Raft
Pedagogy	Historically harder	Leader-centric, decomposed
Leader	Implicit proposer	Explicit roles
Industry docs	Google Chubby lineage	etcd, Consul, TiKV
Your depth	Name phases + Multi-Paxos idea	Walk through election (Topic 6)

etcd / ZK / Kafka controller

• etcd — Raft (Kubernetes leases, config)
• ZooKeeper — Zab (legacy coordination)
• Kafka KRaft — Raft metadata quorum (no ZK)

Know which protocol backs the coordination store you're designing around.

Not required

Simulate acceptor pseudocode. Do explain why metadata stores need a total order broadcast.