Why ZooKeeper Is Not the Best Choice for Service Discovery: Design Considerations for Registration Centers

Reflecting on more than ten years of Alibaba’s internal projects—from the early "Five‑Color Stone" refactoring that birthed ConfigServer to the evolution of Dubbo’s integration with ZooKeeper—this article examines the historical context of service‑discovery solutions and questions whether ZooKeeper remains the optimal registry.

Requirement analysis : A registration center essentially provides a query function Si = F(service-name) , returning a list of endpoints (ip:port) for a given service name. Consistency, partition tolerance, and availability must be balanced according to CAP.

Data‑consistency impact : In a scenario where a service has ten replicas, inconsistent query results (e.g., S1 = {ip1,…,ip9} vs. S2 = {ip2,…,ip10} ) cause traffic imbalance. However, if the registry converges to a consistent state within the SLA (e.g., 1 s), the imbalance quickly disappears, making eventual consistency acceptable.

Partition‑tolerance and availability : Using a typical ZooKeeper 5‑node (2‑2‑1) deployment across three data‑centers, a network partition isolates one data‑center, rendering its leader node unwritable. Consequently, services in that zone cannot be deployed, scaled, or restarted, violating the principle that a registry must never break service connectivity.

Therefore, the design should favor AP over CP: availability is more valuable than strong consistency for a registration center, and temporary inconsistency can be tolerated.

Scale and capacity : As the number of services and instances grows, ZooKeeper’s write throughput and connection count become bottlenecks. While ZooKeeper handles coarse‑grained coordination (locks, leader election) well, its write path does not scale horizontally, making it unsuitable for large‑scale service‑discovery workloads.

Persistence and transaction logs : Although ZooKeeper persists every write via the ZAB protocol and snapshots, the real‑time address list of services does not require durable storage; only metadata (version, group, weight, etc.) needs persistence.

Health‑check design : Relying solely on ZooKeeper session liveness (ephemeral nodes) conflates TCP connectivity with service health. A robust registry should allow custom health‑check logic rather than a one‑size‑fits‑all approach.

Disaster recovery : Clients must continue operating when the registry is completely unavailable. Techniques such as client‑side snapshots and graceful degradation are essential, yet the native ZooKeeper client lacks these capabilities.

Operational complexity : Mastering ZooKeeper’s client/session state machine and handling exceptions like ConnectionLossException , SessionExpiredException , and others requires deep expertise. Mis‑handling can lead to lost events, duplicate operations, or inconsistent state.

In summary, while ZooKeeper excels at coordination for big‑data and offline tasks, its strong consistency, limited write scalability, and operational overhead make it a poor fit for high‑throughput, large‑scale service‑discovery scenarios. Practitioners should consider AP‑oriented, purpose‑built registries (e.g., Eureka) for such workloads.