ZooKeeper is a coordination service for distributed systems. It has been used by systems such as HBase, SolrCloud, Hadoop HDFS high availability, and older Kafka deployments before KRaft. In interviews, the common mistake is treating it as a general-purpose database instead of a small, strongly consistent metadata store.

ZooKeeper is built for small amounts of critical coordination data: who the leader is, which members are present, whether a lock is held, and what the current configuration version is. It is not designed for user data, large blobs, analytics events, or high write throughput.

A strong design answer explains the trade-offs: why ensembles use majority quorum, why odd voting-node counts are common, why watches are usually one-time triggers, and why ZooKeeper refuses progress without quorum instead of risking conflicting coordination state.

This chapter covers the practical knowledge you need for interviews: ensemble architecture, ZAB, znodes, watches, sessions, leader election, distributed locks, service discovery, and when to choose alternatives like etcd or Consul.

The diagram shows how clients reach a ZooKeeper ensemble, how every write is routed through a single leader and acknowledged by a quorum of voting servers, and how reads are served locally from any node.