Index/ZooKeeper

SponsorGitHub
Key technologyCoordination service3 min

ZooKeeper

A small, strongly consistent store for the decisions a cluster must agree on: who leads, who is alive, who owns what.

At a glance

What it is
A replicated store for tiny amounts of cluster metadata
Data
A tree of znodes, each at most a megabyte, usually far less
Consensus
ZAB over 3 or 5 servers; writes commit on a majority
Reads
Any member, possibly stale — sync first when it matters
Primitives
Ephemeral znodes, sequential znodes, one-shot watches
Alternatives
etcd (Raft, behind Kubernetes) and Consul — say "ZooKeeper or etcd"

Key concepts and capabilities

The short listwhat it gives you
Not a database — tiny metadata only: a few thousand writes a second, all through one leader
Majority quorum — writes commit on a majority, so a partitioned minority cannot invent a second leader
Ephemeral znodes vanish when a session stops heartbeating, which is failure detection with no extra machinery
Sequential znodes get a monotonic suffix, giving a total order — and a fencing token
Watches notify once when a znode changes, so joins and failures arrive as events instead of polls
Leader election — lowest sequence number leads, each candidate watches only its predecessor
Fencing tokens — the resource rejects a token lower than the highest it has seen, which is what a Redis lock lacks
Rule it out first — a database lease, a Kafka consumer group, or idempotent work often removes the need
Kafka moved off it to its own Raft quorum, KRaft; knowing that keeps your answer current

Use cases

Electing exactly one leader

The canonical recipe, and the one to be able to sketch. Every candidate creates an ephemeral sequential node; the lowest sequence number leads. Each other candidate watches only the node directly below it, so one failure wakes one client rather than a herd.

FocusClick a node for details

Knowing who is alive, and who owns which shard

Workers register ephemeral nodes; the elected coordinator watches that directory and writes a shard-to-worker map into a znode; workers watch the map. Joins and failures arrive as events, and "exactly one process per shard" holds without anybody polling.

FocusClick a node for details

A lock that survives a GC pause

The reason to use a consensus system rather than a cache for a lock that protects money. The sequence number is a fencing token: the resource remembers the highest it has seen, so a paused holder that wakes up late is rejected instead of writing over the new holder's work.

DatabaseFocusClick a node for details

Config every node must agree on

Feature flags, cluster topology, schema versions: written once through the leader, watched by everyone, and converged on within a heartbeat. Small, rarely written, and read by every node — which is precisely the shape it is built for.

FocusClick a node for details