A Kafka partition has one leader broker: the primary node responsible for its reads and writes. In a bank-transfer stream, producers send transfer events to a topic divided into partitions. Each partition’s leader handles its share of that traffic, allowing work to be spread across brokers. section 1.3
The leader is one of the partition’s replicas. With a replication factor of three, a partition normally has one leader and two followers. Followers fetch new messages from the leader; if the leader fails, a follower can take over. Leaders are distributed across brokers rather than concentrated on one server. section 4.2.3 section 1.3
Find the leader of a partition
Run `kafka-topics.sh --describe --topic products.prices.replication --bootstrap-server localhost:9092`. In the three-partition example, partition 0 reports `Leader: 2`, partition 1 reports `Leader: 3`, and partition 2 reports `Leader: 1`. `Replicas` lists brokers storing each partition; `Isr` lists those currently in sync. A shorter `Isr` list than `Replicas` signals that a replica may be lagging or a broker may have failed. section 4.2.3
A producer or consumer need not start by connecting to the correct leader. It connects to a bootstrap broker, requests metadata identifying partition leaders, then uses that information to reach the responsible brokers. For production bootstrap settings, provide multiple brokers so a client can still start if one is down. section 7.4 section 9.1
The leader also determines when a producer receives an acknowledgment. With `acks=all`, it waits until all in-sync replicas have the message. With `acks=1`, it acknowledges receipt sooner, but a failure before followers fetch the message can lose it. With `acks=0`, the producer waits for no acknowledgment. Choose this setting with the required reliability and latency in mind. section 5.1.1 section 8.2
