This phase closes with Zab — the protocol underlying Apache ZooKeeper, a system so central to distributed infrastructure that Phase 8.2 gives it a full dedicated article. Zab is, by design and by its own authors' explicit framing, closer to article 4.3's atomic broadcast problem than to Paxos's single-value consensus framing — and that framing choice comes with one specific, deliberate guarantee that neither Paxos nor Raft makes as a first-class promise: strict FIFO client order, the guarantee that operations from the same client are delivered in the exact order that client sent them, everywhere, always. This article covers Zab's epoch/zxid structure, its two-phase (broadcast, recovery) operational model, and closes Phase 5 with a full comparison table across every classical algorithm covered.
Why ZooKeeper needed its own protocol rather than reusing Paxos directly
ZooKeeper's designers, per their own published rationale, found that off-the-shelf Paxos didn't cleanly provide one specific guarantee their use case needed: primary order — if a client submits operation A and then, after A completes, submits operation B, every server must apply A before B, and this ordering must hold even across leader changes. Plain single-decree Paxos (article 5.2), run independently per value, doesn't inherently preserve this client-submission-order guarantee across a leadership change unless additional care is taken — and ZooKeeper's designers judged it cleaner to build a protocol with this guarantee as a first-class, structural property from the start, rather than layering it on top of a general-purpose consensus primitive after the fact.
Epochs and zxids: Zab's ordering vocabulary
Zab's identifiers directly parallel everything this phase has already built, with its own specific naming: an epoch is Zab's leadership-epoch counter — the fourth independent name this series has now encountered for the same underlying concept (proposal number in Paxos, view number in VR, term in Raft, epoch in Zab). Each transaction is tagged with a zxid (ZooKeeper transaction ID), a 64-bit value structured as (epoch, counter) — the epoch in the high-order bits, a per-epoch monotonically increasing counter in the low-order bits. This composite structure means zxids are totally ordered by simple integer comparison, while still cleanly encoding both "which leadership period" and "which position within that period" in a single value — a compact, elegant encoding of exactly the two-part identity (article 3.2's index+term log entries) this series has seen built up piece by piece across Paxos and Raft.
The two operational phases: Broadcast and Recovery
Broadcast phase (the normal-case fast path)
With a stable leader established, Zab operates much like Multi-Paxos's fast path (article 5.3) or Raft's normal AppendEntries flow (article 5.6): the leader assigns each new transaction the next zxid in sequence and broadcasts a PROPOSAL message to followers; once a majority of followers ACK, the leader broadcasts COMMIT, and every follower applies the transaction in strict zxid order — directly delivering the FIFO client-order guarantee, since each client's successive operations necessarily receive successively higher zxids from the same leader.
Recovery phase (leader election and log synchronization, unified)
When the current leader fails or becomes unreachable, Zab enters recovery: a new leader is elected (using a protocol that, once again, requires majority support — article 3.3's mechanism, doing its familiar work), and — this is the detail worth highlighting, because it differs slightly in emphasis from Raft's explicit decomposition (article 5.5's design philosophy) — Zab tightly unifies leader election with log synchronization into one recovery phase, rather than treating them as cleanly separable sub-problems the way Raft's presentation does. The newly elected leader synchronizes its log with a majority of followers (bringing everyone to a consistent state, directly analogous to article 3.2's catch-up mechanism) as part of the same recovery process that establishes it as leader, before transitioning back into the broadcast phase.
Fig 1 — Zab's recovery phase unifies election and log sync, a structural choice distinct from Raft's explicit decomposition (5.5).
Phase 5 closing comparison: every classical algorithm, side by side
Four algorithms, four independent research efforts, closing out this phase — worth seeing them together, one final time, now that every mechanism has been built up in detail:
| Algorithm | Origin | Leadership-epoch name | Distinctive design emphasis |
|---|---|---|---|
| Paxos (5.1-5.3) | Lamport, 1989/1998, theory-first | proposal number | Foundational proof; Multi-Paxos amortizes Phase 1 across a whole log |
| Viewstamped Replication (5.4) | Oki & Liskov, 1988/2012, systems-first | view number | Practical replication focus; explicit state transfer, request de-duplication |
| Raft (5.5-5.6) | Ongaro & Ousterhout, 2014, understandability-first | term | Deliberate decomposition into independently-provable sub-problems |
| Zab (this article) | Reed & Junqueira / Yahoo Research, ZooKeeper team | epoch | Structural FIFO client-order guarantee; election and recovery unified |
Closing Phase 5
Phase 5 has been the payoff for everything built across Phases 1-4: the full mechanics of Paxos (5.1-5.3), an independent confirmation via Viewstamped Replication (5.4), the most implementation-friendly modern presentation via Raft (5.5-5.6), and a fourth data point via Zab (this article) — a protocol tuned for one specific additional guarantee (FIFO client order) that the others leave as an external concern. Every one of these algorithms rests on the identical majority-overlap safety foundation this series established in article 3.3, confirming that foundation isn't one lab's arbitrary choice but close to the natural, structurally-forced answer to the problem article 5.1 stated precisely.
Phase 6 now turns to a genuinely different failure model — Byzantine failures, where nodes don't merely crash but can actively lie — starting with the Byzantine Generals Problem and building up through PBFT, HotStuff, Tendermint, and the Narwhal/Bullshark lineage that powers much of the blockchain and high-throughput BFT world. The majority-quorum mechanism this phase relied on so heavily will need real reinforcement to survive adversarial, not just unreliable, participants.
FAQ
Is Zab's FIFO client-order guarantee something Raft/Paxos genuinely can't provide?
They can provide it, but as an additional layer built on top rather than as a structural, first-class protocol guarantee — a client-side sequencing mechanism or an application-level ordering scheme can achieve the same effect on top of vanilla Raft or Paxos. Zab's distinction is making it a built-in, protocol-level guarantee rather than something every application built on top must separately re-implement.
Does unifying election and recovery (unlike Raft's decomposition) make Zab harder to reason about?
Somewhat, per the understandability lens article 5.5 introduced — Zab's own documentation and academic treatments are generally considered denser than Raft's paper, echoing the exact presentation-clarity theme this whole phase has traced through Paxos, VR, and Raft. This is a genuine, acknowledged trade-off Zab's designers made in favor of the FIFO guarantee's structural simplicity, at some cost to the protocol's own explanatory clarity.
Why does ZooKeeper get its own dedicated production-systems article later (Phase 8.2) if Zab is already covered here?
This article covers Zab as a consensus/atomic-broadcast algorithm on its own terms, matching this phase's algorithm-by-algorithm structure; Phase 8.2 covers ZooKeeper as a production system — its data model (the hierarchical znode namespace), its client API, ephemeral nodes and watches, and its real-world operational characteristics — a genuinely different, complementary angle.
Is there a "best" algorithm among the four covered in Phase 5?
Not in any absolute sense — each makes a different, defensible trade-off (Paxos's foundational generality, VR's practical replication focus, Raft's understandability, Zab's structural FIFO guarantee), and Phase 9's coverage of real production systems shows all four lineages still actively deployed today. "Best" depends entirely on which specific extra guarantees and presentation trade-offs matter most for a given system's requirements — exactly the kind of judgment call this series has been building the vocabulary to make throughout.
Takeaways
- Zab underlies Apache ZooKeeper, framed by its designers closer to article 4.3's atomic broadcast problem than to single-value Paxos, specifically to make FIFO client order a first-class, structural guarantee.
- Epochs and zxids — Zab's fourth independent name for the leadership-epoch counter, with zxids elegantly encoding both epoch and per-epoch position in one totally-ordered 64-bit value.
- Zab's Broadcast phase (normal-case fast path) and Recovery phase (leader election unified with log synchronization, unlike Raft's explicit decomposition) are the two operational modes.
- The Phase 5 closing comparison across Paxos, VR, Raft, and Zab shows four independent research efforts converging on the identical majority-overlap safety mechanism (article 3.3) — strong evidence it's close to the natural, forced solution, not an arbitrary choice.
- Phase 5 is now complete. Phase 6 (Byzantine Consensus) introduces a genuinely different failure model — adversarial, lying participants — that will finally require real mechanism changes, not just presentation differences.
References & further reading
- Reed & Junqueira — A Simple Totally Ordered Broadcast Protocol (Zab, 2008) — the primary Zab reference.
- Hunt, Konar, Junqueira & Reed — ZooKeeper: Wait-free Coordination for Internet-scale Systems (2010) — the ZooKeeper system paper; full production coverage in Phase 8.2.
- cvam.sight — Consensus 4.3: Atomic Broadcast — the equivalence framing Zab's own design rationale is built on.
- cvam.sight — Consensus 5.1: Paxos, History and the Problem — the problem statement all four algorithms in this phase solve.
- cvam.sight — Consensus Algorithms series hub — Phase 6 (Byzantine Consensus) picks up next.