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.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.