When a partition leader stops responding, producers cannot simply send writes to whichever replica answers first. Kafka must establish which replica has authority to continue the log, then make that decision available to brokers and clients.
That process is partition leader election. It lets Kafka recover from failures and move leadership during maintenance, while controlling whether recovery preserves committed records or risks losing them.
We’ll follow elections in an Apache Kafka 4.3 KRaft cluster. The examples use local storage, non-transactional records, and consumers fetching from leaders. Assume the cluster enables Eligible Leader Replicas, or ELR, as it is by default for new clusters starting with Kafka 4.1. Upgraded clusters may have a different feature state.