Brokers, Replication and KRaft

Copies for safety

A Kafka cluster is a set of brokers (servers). Each partition has a replication factor (commonly 3): one broker holds the leader replica that serves all reads and writes for that partition, and the others hold follower replicas that copy it. The followers that are fully caught up form the in-sync replicas (ISR). If the leader fails, one ISR member becomes the new leader. Cluster metadata (which broker leads which partition) is managed by KRaft, Kafka's own consensus protocol; ZooKeeper was removed in Kafka 4.0, so new clusters use KRaft.

Partition layout from a real broker

I started a single-node Kafka 3.9.0 (KRaft) in Docker and ran kafka-topics.sh --describe. Each partition shows its leader, replicas and ISR. With one broker, replication factor is 1, so each partition is led by broker 1 with only itself in the ISR. In a real cluster you would see several broker IDs.

kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders

Output:

Topic: orders	TopicId: aWjqjntwSYmI_PLyTqQcLA	PartitionCount: 6	ReplicationFactor: 1	Configs: segment.bytes=1073741824
	Topic: orders	Partition: 0	Leader: 1	Replicas: 1	Isr: 1
	Topic: orders	Partition: 1	Leader: 1	Replicas: 1	Isr: 1

Use replication factor 3 in production

A factor of 1 (fine for a laptop) means losing that broker loses the data. Three replicas across different racks or availability zones is the common production baseline.

Quick check: What is the ISR?

• The producer buffer
• The list of consumers
• A kind of topic
• The replicas that are fully caught up with the leader