Zookeeper
Coordination service for distributed systems — leader election, config, locks, and membership with strong consistency.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Zookeeper is non-negotiable.
① What it is (30 seconds)
Coordination service for distributed systems — leader election, config, locks, and membership with strong consistency.
② How it works in system design
Znodes in a hierarchical namespace. Watches notify clients of changes. Quorum writes for consistency (CP). Used for Kafka controller election, Hadoop, early service discovery.
Typical placement
Client→Edge / Gateway→Zookeeper→Services→Data stores
③ Concrete system design example
Scenario: Distributed task scheduler: only one leader znode holder runs cron tick. Challenger watches leader node; on session timeout, new leader elected in seconds.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Zookeeper vs etcd? | Similar coordination; etcd common in Kubernetes; ZK legacy in Kafka ecosystem. |
| Why not use DB for locks? | ZK optimized for small coordination data + watches; not for bulk storage. |
| Split brain risk? | Requires quorum majority; never run even number of nodes in production. |
⑤ Seen in these system designs
- Task Scheduler — leader election
- Kafka — controller metadata
- Distributed Search — cluster metadata
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Znode watches
- Leader election
- Quorum size
- CP not AP
- Session timeouts