How does Kafka handle partition leader election?

When a partition's current leader broker fails or becomes unreachable, the KRaft active controller detects this (via missed heartbeats/session timeout) and selects a new leader from among that partition's in-sync replicas (ISR), then propagates the new leader assignment through the metadata log so every broker and client learns about it.

By default, Kafka only promotes an in-sync replica — one that was fully caught up with the old leader — which guarantees no committed data is lost in the handover. If every replica in the ISR is also unavailable at the same time (a broader outage), the partition simply becomes unavailable for writes rather than silently promoting an out-of-sync replica and risking data loss, unless unclean.leader.election.enable is explicitly turned on to allow that riskier trade-off. Clients (producers and consumers) discover the new leader automatically on their next metadata refresh or when a request to the old leader fails, without needing any manual reconfiguration.