Educational deep-dive: partitions, ISR, leader election, KRaft consensus, replication, consumer rebalancing
This visualization shows how Apache Kafka works at the broker level -- the internal mechanics that make Kafka a reliable, high-throughput distributed streaming platform.
Unlike a high-level pipeline diagram, this focuses on how messages actually flow inside a Kafka cluster: partition leaders and followers, In-Sync Replicas (ISR), the High Watermark mechanism, KRaft consensus, and consumer group coordination.
Three application services (Order, Payment, User) produce messages to different partitions based on key hashing: hash(key) % numPartitions.
Each broker hosts all 3 partitions, but in different roles:
This distribution ensures no single broker failure loses all leaders.
Replaces ZooKeeper (deprecated since Kafka 3.3). Three controller nodes use Raft consensus to manage cluster metadata: broker registration, partition assignments, leader elections.
The set of replicas that are fully caught up with the leader. When acks=all, the producer waits for ALL ISR replicas to acknowledge before confirming the write. If a follower falls behind, it's removed from ISR.
The offset up to which all ISR replicas have replicated. Only messages below HW are visible to consumers. This prevents consumers from reading data that might be lost if the leader fails.
The offset of the last message in a replica's local log. Each replica tracks its own LEO. The leader uses follower LEOs to determine when to advance the High Watermark.
When consumers join or leave a group, the group coordinator (a specific broker) triggers a rebalance protocol: all consumers stop, commit offsets, receive new partition assignments, and resume.