liveBook · Manning

Raft

As explained in Kafka for Architects

Raft is a consensus algorithm that coordinates replicated state among nodes and commits updates after acknowledgment by a quorum.

Raft coordinates replicated state among controllers by committing an update only after a majority of followers acknowledge it. In Kafka’s KRaft architecture, controllers store cluster metadata in Raft logs, while brokers retrieve and serve that metadata to clients. section 9.1.1

The architecture establishes several important boundaries:

  • Only controllers participate in the metadata quorum and write the metadata log; brokers may keep read-only local copies. section 9.1.1
  • A newly elected controller leader has all committed entries, avoiding committed-data loss after leader change. section 9.1.1

How Kafka for Architects covers it

How deep it goes
Explains leader commitment, follower acknowledgment, election safety, quorum loss, and metadata-log boundaries.
Examples
Uses metadata-log replication, controller quorum, data-center placement, snapshots, and broker metadata requests as concrete examples.
What you can do after
Evaluate controller placement and metadata-consistency consequences using quorum and leader-election behavior.
How it connects
Connects consensus algorithms with KRaft, controller quorum, metadata logs, leader election, and broker replication.
Cover of Kafka for Architects
liveBookmanning.com
Read Kafka for Architects on liveBook Get the book at manning.com

Also explained in

Compare how 3 books explain Raft →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kafka for Architects. The section links point to the parts of the book it draws on.