ZooKeeper Atomic Broadcast (ZAB) is the consensus protocol that powers Apache ZooKeeper — the coordination service behind Kafka, HBase, Solr, and countless other distributed systems. It predates Raft and diverges from Paxos in one crucial way: ZAB is designed for primary-backup replication with strict ordering guarantees, not for agreeing on a single value at a time.

The core insight: ZooKeeper's clients issue a stream of state-mutating operations, and every replica must apply them in the exact same order. Paxos gives you agreement on individual values but doesn't natively guarantee total order across a sequence. ZAB bakes total order in from the start.

How it works. ZAB has two modes:

• Broadcast mode (steady state): The leader assigns each transaction a monotonically increasing zxid (a 64-bit ID where the high 32 bits are the leader's epoch and low 32 bits are a counter). It sends a PROPOSE to followers, waits for ACKs from a quorum, then sends COMMIT. Followers apply transactions in zxid order — no gaps allowed.
• Recovery mode (leader change): When the leader dies, followers elect a new leader via Fast Leader Election. The new leader must have the highest zxid seen by any quorum member — this guarantees no committed transaction is ever lost. The new leader then syncs followers up to its state before bumping the epoch and re-entering broadcast mode.

The zxid trick. Because the high 32 bits encode the epoch, transactions from a new leader are always ordered after those from the old leader, even if the counter resets. A follower comparing (epoch=5, counter=100) vs (epoch=6, counter=1) immediately knows the second is newer. This makes recovery reasoning tractable.

Real-world example: Kafka historically used ZooKeeper to store broker metadata, topic configurations, and consumer offsets. When a broker updated a topic's partition assignment, that write went through ZAB: leader proposed it, quorum acked, all ZooKeeper nodes applied it in the same order. This is why two Kafka brokers reading ZooKeeper at the same time never see contradictory topic state — ZAB's total ordering guarantees it. (Kafka has since moved to KRaft, its own Raft implementation, but the pattern persisted for a decade.)

Rule of thumb: ZAB needs a quorum of ⌊N/2⌋ + 1 nodes to make progress, same as Paxos/Raft. For a 5-node ensemble, you can lose 2 and still commit. But every write requires 2 round trips (PROPOSE + COMMIT) — so expect ~2× the base network latency per write.

When ZAB vs Raft? If you're building from scratch today, use Raft — it's better documented and has more library support. Choose ZooKeeper (and thus ZAB) when you need a proven coordination service with mature client libraries, watches, and ephemeral nodes.