ZooKeeper and etcd
Why distributed systems need a small, strongly consistent coordination service, how Raft and ZAB keep it correct, and how leader election, locks and discovery use it.
Why coordination services exist
Many servers must agree on small facts: who is the leader, which servers are alive, what the current config is, who holds a lock. Each server asking its own database or guessing from timeouts leads to split brain: two servers both believe they are the leader and both write, corrupting data.
A coordination service is a tiny, replicated store whose job is to be the single source of truth for those facts. It trades speed and size for strong correctness:
- Holds kilobytes, not gigabytes. It is a control-plane tool (decides things), not a data-plane tool (stores your data).
- Every write is agreed by a majority of its servers before it is acknowledged.
- Reads see the latest committed value (etcd by default; ZooKeeper if you ask).
The two classic ones: Apache ZooKeeper (2008, Java, born at Yahoo, used by Hadoop and old Kafka) and etcd (2013, Go, born at CoreOS, the brain of Kubernetes). Consul is a third, focused on service discovery.