When ZooKeeper becomes unavailable, a running Kafka cluster (in the legacy ZooKeeper-based mode) continues serving existing reads and writes on already-elected partition leaders, but it loses the ability to perform any cluster metadata changes until ZooKeeper is restored.
Key Points: • Brokers that already know their partition leadership keep serving produce and consume requests normally during the outage. • Kafka cannot elect new partition leaders, so if a broker fails while ZooKeeper is down, those partitions become unavailable until ZooKeeper recovers. • New brokers can't properly join the cluster and topic/ACL/configuration changes can't be applied while ZooKeeper is unreachable. • Newer Kafka versions running in KRaft mode remove this dependency entirely by storing metadata in a Raft-based controller quorum instead of ZooKeeper.
Example: If ZooKeeper goes down for a few minutes on a stable cluster with no broker failures, producers and consumers may not even notice, but if a broker crashes during that same window, its partitions stay leaderless and unavailable until ZooKeeper comes back and a new leader can be elected.
Interview Tip: A concise interview answer is:
"During a ZooKeeper outage, existing Kafka brokers keep serving reads and writes on partitions they already lead, but the cluster can't perform metadata operations like leader election or adding brokers until ZooKeeper is restored — which is one of the main reasons newer Kafka deployments move to KRaft mode to remove that dependency entirely."