ZooKeeper

ZooKeeper is a coordination service for distributed systems. Once you have a cluster of machines, they need to agree on things: who's the leader, which nodes are alive, what the current configuration is, who holds a given lock. Getting that agreement right under failures is genuinely hard — that's the consensus problem — and ZooKeeper is a battle-tested building block that solves it so individual systems don't have to.

The problems it solves

• Leader election. Many systems need exactly one node in charge (one writer, one scheduler). ZooKeeper lets nodes elect a leader and automatically pick a new one if it dies — no split-brain.
• Service discovery / membership. Nodes register themselves; others see who's currently alive. When a node dies, its registration disappears, so the cluster notices.
• Configuration management. A single consistent place for cluster-wide config that every node reads and watches for changes.
• Distributed locks & coordination. A correct lock across machines, so only one node does a given task at a time.

How it works, briefly

ZooKeeper keeps a small, hierarchical key-value tree (like a filesystem of "znodes") replicated across an odd number of nodes (an ensemble of 3 or 5). Writes go through a consensus protocol so a majority (quorum) must agree — which is why it stays correct under failures but needs a majority up to accept writes. Two features make it useful for coordination:

• Ephemeral nodes vanish when the client that created them disconnects — perfect for "is this node still alive?" and for locks that must release if the holder crashes.
• Watches let a client be notified the instant a node changes — so leader changes and config updates propagate immediately.

Where you actually meet it

You rarely build on ZooKeeper directly. You meet it inside other systems that use it for coordination — Kafka (historically, for cluster metadata and controller election), Hadoop, and others. The lesson for interviews isn't the API; it's recognising the need: whenever a distributed system requires leader election, consensus, membership, or a cross-node lock, a coordination service like ZooKeeper (or etcd, or Consul) is the thing that provides it.

ZooKeeper vs etcd vs Consul

They're siblings. etcd (used by Kubernetes) and Consul solve the same consensus/coordination problem with similar guarantees; etcd is the common modern choice for new systems and for Kubernetes-adjacent work. Pick based on ecosystem — the concept is identical.

What to watch

• It's for coordination, not data. Store small, critical metadata (who's leader, config), never your application data or large values.
• Quorum availability. It needs a majority of the ensemble up; size it (3 or 5 nodes) for the failures you want to tolerate.
• Another system to run. Only introduce it when you genuinely need distributed coordination — most apps lean on a database or Redis lock for simpler needs.

What to say in an interview

Name the coordination need, then the service that fills it:

"The ingestion cluster needs exactly one leader assigning work, and must fail over cleanly if that node dies. That's a consensus problem, so I'd use a coordination service — ZooKeeper or etcd — for leader election and membership via ephemeral nodes and watches, rather than trying to hand-roll agreement. It only holds coordination metadata, not the data itself."

---

That completes Key Technologies. The Advanced Topics section goes deeper on a few specialised problems.