A broker failure occurs when a Kafka broker becomes unavailable or cannot serve partition data. In a large payment-processing system, one broker may become unresponsive during peak traffic. Kafka can continue serving producers and consumers, but the result depends on replication, in-sync replicas, and producer acknowledgments. section 16.1.2
Use replication and acknowledgment settings to determine the practical failure boundary:
- With replication.factor=3 and min.insync.replicas=2, one lost broker causes no immediate producer or consumer impact when producers use acks=all. section 16.1.2
- After a second broker is lost in that configuration, acks=all producers cannot publish, while consumers can continue if a leader replica remains available. section 16.1.2
- Increasing replication.factor to four while retaining min.insync.replicas=2 allows two broker failures without affecting producers or consumers, although traffic concentrates on fewer brokers. section 16.1.2
- Higher replication protects against broker failures but increases cluster cost and does not protect against human mistakes; multi-cluster designs provide additional reliability. section 16.1.2
Recovery generally begins by bringing the failed broker back online. Broker problems can cause data loss when messages were not properly committed, so acks=all and a sufficient in-sync replica count are central to delivery assurance. For broader disaster resilience, stretched clusters and active-active mirrored clusters can preserve operation across data-center or cluster failures. section 16.1.2 section 16.4
