If you have spent any time working with distributed systems, you have probably run into Zookeeper. It powers coordination in Kafka, HBase, Solr, and countless internal systems at large companies. Yet in interviews, I often see candidates either treat it as a magic black box or confuse it with a general-purpose database.

Here is the thing: Zookeeper is neither magic nor a database. It is a coordination service, purpose-built for small amounts of critical data that absolutely must stay consistent across a distributed system. Think of it as the nervous system that helps your services agree on who the leader is, whether a lock is held, or what the current configuration looks like.

The difference between a good interview answer and a great one often comes down to understanding not just what Zookeeper does, but why it makes the design choices it does. Why does it use odd-numbered clusters? Why are watches one-time triggers? Why does it prioritize consistency over availability?

This chapter covers the practical knowledge you need to discuss Zookeeper confidently in interviews: the ZAB consensus protocol, znode types, watches, leader election patterns, and when Zookeeper is the right choice versus alternatives like etcd or Consul.

1. When to Choose Zookeeper