Distributed Consensus Reloaded: Apache ZooKeeper and Replication in Apache Kafka | Confluent
Aug 27, 2015Flavio Junqueira

Summary
This post explains the fundamental problem of distributed consensus and how systems like ZooKeeper solve it by implementing atomic broadcast. It details how Kafka leverages ZooKeeper for metadata management, including broker sets, leader election, and eligible leader subsets. The post also highlights potential pitfalls in reasoning about consensus and agreement, using an example of workers consuming different flavors due to timing differences in ZooKeeper reads. It contrasts ZooKeeper's role as a 'coordination kernel' with explicit consensus APIs and explains how Kafka uses ZooKeeper's sequential nodes and state updates to achieve agreement on leader replicas.
More from the Kafka KRaft Migration trail
- Announcing Confluent Platform 8.3: Powerful Apache Flink® SQL operations, Easier KRaft Migrations, Expanded Monitoring and more
- Apache Kafka 4.3 released: 25 KIPs, Kafka Streams, Share Group Controls, Broker Isolation, and more
- Introducing Confluent Platform 8.2: Queues for Kafka & Flink SQL
- Migrate From Hosted Kafka to Confluent Cloud in the KRaft Era
- Apache Kafka 4.1 Release: New Features & Upgrade Guide