If ZooKeeper were to fail entirely (in a legacy ZooKeeper-based Kafka deployment), the cluster would lose its ability to manage metadata — broker membership, partition leadership, and configuration changes — even though already-running brokers would keep serving existing traffic for a while.
Key Points: • Brokers that already have an assigned leader for their partitions continue serving reads and writes normally in the short term. • No new leader elections can happen, so any broker failure during the outage leaves its partitions unavailable. • New brokers can't join the cluster and configuration or ACL changes can't be applied. • Over a prolonged outage, client metadata can become stale and operational issues compound since the cluster can't self-heal. • This single point of coordination is a major reason Kafka introduced KRaft mode, which replaces ZooKeeper with a built-in Raft-based controller quorum.
Example: A cluster that loses ZooKeeper during a quiet period with no broker failures might see no visible impact for a while, but the moment any broker crashes, its partitions become stuck without a new leader until ZooKeeper is restored.
Interview Tip: A concise interview answer is:
"A ZooKeeper failure wouldn't immediately stop existing brokers from serving traffic, but it would freeze all cluster coordination — no new leader elections, no broker additions, no config changes — so any subsequent broker failure during that window would cause real unavailability, which is exactly the single point of failure that KRaft mode was built to remove."