Why should unclean leader election be disabled in most production clusters?

unclean.leader.election.enable controls what happens when every in-sync replica of a partition is unavailable at the same time as the leader — a genuinely rare but real failure scenario. When disabled (the default and generally recommended setting), Kafka simply leaves that partition unavailable for writes until an in-sync replica comes back, guaranteeing no committed data is silently lost in the handover.

unclean.leader.election.enable=false

Enabling it lets Kafka instead promote an out-of-sync replica — one that was behind the old leader — to keep the partition available for writes sooner. The cost is real data loss: any records the old leader had that the promoted, out-of-sync replica never received are gone permanently, and worse, new writes to the promoted replica can silently overwrite what would have been the "true" continuation of the log, producing inconsistent history that's hard to detect after the fact. Most production systems value correctness over availability for this specific trade-off and leave it disabled; it's really only defensible for use cases (like some metrics or logging pipelines) where brief availability matters more than occasional, hard-to-notice data loss.