A Kafka partition has one primary replica, called its leader. Other replicas are followers. Leaders for different partitions can live on different brokers, distributing work across the cluster. This is a data role: a partition leader is not the active KRaft controller, which manages cluster metadata and broker coordination. section 2.3.1 section 1.3.2
A producer sends a message to the partition’s leader, not to every replica. Followers query the leader and pull new data asynchronously. That delay means the leader can hold messages that followers have not yet copied; replicas may therefore contain different amounts of data at a given moment. section 2.3.1
The leader’s role creates two practical design concerns:
- Write reliability depends on replication, not merely on reaching the leader. An in-sync replica (ISR) has caught up with the leader; min.insync.replicas sets how many in-sync replicas must be available for a successful write. If too few are available, the producer receives an exception. section 2.3.1
- Producers must locate the current leader. A client library requests and caches broker-to-partition-leader metadata. If leadership changes and a send reaches the former leader, the library refreshes metadata and resends the batch to the new leader. section 3.2
A write during a leadership change
A producer has cached the broker hosting a partition leader. Leadership changes before its next send, so the cached destination returns a temporary error. The client library obtains fresh metadata and retries against the newly selected leader. The application may see an informational log message rather than needing to route the batch itself. section 3.2
Figure 2.10 Each partition has one replica designated as the leader, while the others serve as followers.
The partition layout shows one leader alongside its followers, making clear that leadership belongs to a partition replica rather than to every broker as a whole. section 2.3.1
