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

Looking back at the history of Alibaba's internal projects, the "Five‑Color Stone" refactoring in 2008 led to the creation of ConfigServer, while ZooKeeper emerged as an open‑source coordination service after Yahoo promoted it based on Google’s Chubby and Paxos papers.

ZooKeeper became an Apache top‑level project in 2010 and was later adopted by Dubbo as its default registry, giving ZooKeeper a strong reputation as a registration center.

The article asks whether ZooKeeper is truly the best choice for service discovery and examines this through the lens of the CAP theorem. It shows that a registry’s core function is a simple query:

Si = F(service-name) where service-name returns a list of endpoints (ip:port) .

Inconsistent endpoint lists across replicas cause temporary traffic imbalance, but if the registry converges to eventual consistency within the SLA (e.g., 1 s), the impact is acceptable.

When a network partition occurs, ZooKeeper’s CP nature can make a whole data center’s services unavailable for registration, scaling, or health checks, violating the principle that a registry must never break intra‑datacenter connectivity; therefore, an AP‑oriented design is preferred.

Scalability analysis shows that as the number of services and instances grows, ZooKeeper’s write throughput becomes a bottleneck, especially for frequent registration and health‑check updates, making it unsuitable for massive service‑discovery workloads.

Persisting the real‑time address list is unnecessary; only metadata (version, group, weight, etc.) needs durable storage. Health‑check mechanisms should be richer than simple TCP session liveness, allowing services to define their own health logic.

Disaster‑recovery considerations require the client to cache registry data (client snapshot) so that temporary registry outages do not affect service calls, and the registry itself must remain highly available.

Exception handling in ZooKeeper is complex: developers must understand and correctly handle ConnectionLossException , SessionExpiredException , and related events, ensuring idempotent operations and proper retry logic.

Finally, the article advises that while ZooKeeper excels in coordination for big‑data workloads, it should be avoided for high‑throughput service discovery; instead, choose a registry designed for AP characteristics and tailored health checks.