Why ZooKeeper Isn’t the Best Choice for Service Discovery: Design Insights

Service Registry Requirements and Key Design Considerations

Looking back at the evolution of service discovery, Alibaba’s internal projects such as ConfigServer (born in 2008) and the widespread adoption of ZooKeeper illustrate how registration centers have become critical infrastructure.

Consistency vs. Availability

In the CAP model, a registry’s core function is a query Si = F(service-name) that returns the list of endpoints (ip:port). Inconsistent endpoint lists cause traffic imbalance, but eventual consistency within a short SLA (e.g., 1 s) is acceptable.

Note: service is abbreviated as svc in the following text.

When a service with 10 replicas returns different endpoint sets to callers, the traffic distribution becomes uneven. However, as long as the registry converges quickly, the impact is minimal.

Partition Tolerance and Availability

Consider a three‑datacenter ZooKeeper deployment (2‑2‑1). If one datacenter becomes isolated, its nodes cannot write because they lose contact with the leader, preventing new deployments or scaling in that zone, which violates the principle that a registry must never break service connectivity.

In practice, availability outweighs strict consistency for registries; they should be designed as AP systems, tolerating temporary inconsistencies.

Scale and Capacity

When service counts grow to hundreds or thousands, ZooKeeper’s write throughput and connection count become bottlenecks. While suitable for coarse‑grained coordination, ZooKeeper cannot handle the high‑frequency writes of service registration and health checks at large scale.

Persistence and Transaction Logs

ZooKeeper’s ZAB protocol logs every write and snapshots data to disk, which is valuable for coordination data but unnecessary for volatile service address lists that only need the latest state. However, metadata such as version, group, weight, and auth policies must be persisted.

Service Health Check

Using ZooKeeper’s session and ephemeral nodes ties health detection to TCP connection liveness, which does not guarantee actual service health. Registries should provide richer, pluggable health‑check mechanisms defined by the service itself.

Disaster Recovery

Service calls must remain functional even if the registry is completely down; clients should rely on cached snapshots and only contact the registry for registration, scaling, or failure events.

Complexity of ZooKeeper Clients

Understanding ZooKeeper’s client/session state machine is challenging. Exceptions like ConnectionLossException (recoverable) and SessionExpiredException (non‑recoverable) require careful handling to maintain correct service state.

Conclusion

ZooKeeper excels at coarse‑grained coordination for big‑data workloads, but for large‑scale service discovery it often falls short. Registries should prioritize availability, support flexible health checks, and avoid over‑reliance on ZooKeeper’s strong consistency when designing modern cloud‑native service discovery solutions.