# ZooKeeper vs etcd > ZooKeeper centers on hierarchical coordination primitives; etcd centers on a versioned key-value API with transactions, leases, and revision-based watches. Choose ZooKeeper when existing systems or coordination recipes depend on its session and znode model; choose etcd when building a control plane that benefits from explicit revisions, conditional updates, and linearizable reads. Source: https://sysround.com/compare/zookeeper-vs-etcd Updated: 2026-11-05 ## Side by side | | ZooKeeper | etcd | |---|---|---| | Data model | Tree of znodes with data and metadata | Flat key space with prefix queries and MVCC revisions | | Replication protocol | Zab atomic broadcast | Raft consensus | | Read consistency | Ordinary reads can return stale data | Linearizable by default; optional stale reads | | Conditional updates | Version checks and atomic multi-operations | Compare-and-swap transactions across keys | | Liveness tracking | Ephemeral znodes tied to a session | Keys attached to renewable TTL leases | | Change notifications | Traditional one-shot watches; persistent modes also available | Revision-based watch streams with retained-history replay | | Locking and election | Common recipes use ephemeral sequential znodes | Concurrency APIs use leases and transactions | | Operational concerns | Session churn, watch load, snapshots, transaction logs | Lease churn, watch load, compaction, defragmentation, quotas | ## The differences that matter The data model changes how you express coordination. ZooKeeper naturally represents membership and election candidates as children under a path, often using ephemeral sequential znodes. In etcd, controllers usually operate on key prefixes and use transactions that compare values, versions, or revisions before changing state. Both can coordinate ownership, but their client recipes are not interchangeable. Read semantics matter when making ownership decisions. ZooKeeper orders writes globally, but an ordinary read from a replica may lag; freshness-sensitive workflows need the appropriate synchronization or conditional-write protocol. etcd provides linearizable reads by default, while its optional serializable reads may be stale. Neither system makes a read followed by an unconditional write atomic. Watch recovery changes controller design. Traditional ZooKeeper watches are one-shot notifications that prompt clients to reread state and register again; persistent watch modes also exist. etcd lets a client watch from a revision and replay retained changes. If that revision has been compacted, the client must reload a snapshot and restart its watch without leaving a gap. Failure detection uses different abstractions but has the same limitation. ZooKeeper removes ephemeral znodes after session expiration; etcd removes leased keys after lease expiration. A paused or partitioned process can keep running after losing ownership. For either system, protect external writes with a monotonically increasing fencing token that the target resource actually checks. ## Choose ZooKeeper when - An existing platform already uses ZooKeeper, and retaining its operational tooling and client libraries avoids an unnecessary coordination-system migration. - The design relies on established ephemeral sequential znode recipes for election, lock queues, or membership. - Hierarchical paths and child membership are a natural fit for the coordination state. - A required component explicitly depends on ZooKeeper APIs or session semantics. ## Choose etcd when - A new control plane needs conditional updates across several configuration or ownership keys. - Controllers need an explicit snapshot revision and resumable watches over retained changes. - Freshness-sensitive metadata reads should be linearizable by default rather than require a separate read-synchronization pattern. - Renewable leases attached to groups of keys fit the service-registration or worker-ownership model. ## Worked example: Fencing database failover Suppose a database control plane manages 2,000 shards with three controller instances. Each shard has an owner record and an ownership epoch. With etcd, a controller can conditionally update ownership using a transaction and watch changes by revision. With ZooKeeper, it can use ephemeral election nodes plus version-checked metadata updates. Now pause the active controller for 40 seconds while its session or lease expires and another controller takes over. The old process may resume and issue commands. Neither coordination service alone prevents that command from reaching a database agent. The agent must reject commands carrying an older epoch. Choose the store based on API fit and operational experience, but make fencing part of either design. ## In the interview - Start with the invariant: for example, only one controller may authorize writes for a shard epoch. Explain the atomic ownership transition and fencing protocol before naming either product. - Separate the control plane from the data plane. Store membership, configuration, and ownership metadata here, not every request, queue message, or application record. - Explain quorum loss explicitly. A three-voter cluster tolerates one voter failure, but an isolated minority cannot safely accept writes; cached routing information may remain usable under a separate freshness policy. - Expect probes about process pauses, lost sessions or leases, and ambiguous request outcomes. Also explain how a controller rebuilds state after a watch disconnect or history compaction. ## Common mistakes - Claiming that ZooKeeper uses Paxos. Its replication protocol is Zab; etcd uses Raft. - Assuming every ZooKeeper read is linearizable, or choosing etcd's optional stale reads for an ownership decision without checking the consequences. - Treating lock acquisition or lease expiration as sufficient protection against a former owner. External resources need fencing or another enforceable concurrency check. - Treating watches as a permanent event log or expiration as an exact wall-clock deadline. Clients need state reconciliation, and failure-detection timing depends on timeouts and operating conditions. ## Interview questions where it comes up - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Controller election, ownership epochs, configuration watches, and fenced failover make this comparison directly relevant. - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): A coordination service can manage shard ownership and membership while remaining outside the cache request path. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): Scheduler leadership and worker ownership require lease or session handling, recovery, and protection against stale owners. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Partition leadership metadata and safe failover require coordinated ownership changes and enforceable leader epochs. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): A separate coordination layer can manage partition assignments and configuration without replacing the store's own replication protocol. ## FAQ ### Is etcd a replacement for ZooKeeper? It can replace ZooKeeper's role in many coordination designs, but it is not API-compatible. A migration must translate session behavior, ephemeral nodes, sequential-node recipes, watches, and conditional updates. Recheck failure recovery and fencing rather than only translating CRUD calls. ### Are ZooKeeper and etcd both strongly consistent? Both use quorum-based replication to maintain an ordered, consistent history of committed writes. Their read APIs differ: ordinary ZooKeeper reads may be stale, while etcd reads are linearizable by default unless the caller requests serializable mode. State the operation and read mode instead of labeling every interaction simply 'strongly consistent.' ### Which is better for distributed locks, ZooKeeper or etcd? Both support distributed lock implementations: ZooKeeper commonly uses ephemeral sequential nodes, while etcd provides lease-backed concurrency APIs. Prefer a well-tested library that matches your infrastructure. In either case, a lock does not stop a paused former owner from acting, so correctness-sensitive external writes still need fencing. ## Related concepts - [Consensus algorithms](https://sysround.com/concepts/consensus) - [Linearizability](https://sysround.com/concepts/linearizability) - [Distributed locks and fencing tokens](https://sysround.com/concepts/distributed-locks) - [Leader election](https://sysround.com/concepts/leader-election) - [Service discovery](https://sysround.com/concepts/service-discovery) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.