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

In this article, a senior architect shares over ten years of Alibaba’s production experience with ZooKeeper as a service registry, arguing that ZooKeeper is not the best choice for service discovery and outlining the design principles for a modern registration center.

Is ZooKeeper the Best Choice for Service Discovery?

The author questions the historical assumption that ZooKeeper should be the default registry, noting that while it excels in coordination tasks, its write scalability and strict consistency model make it unsuitable for large‑scale service discovery.

Registration Center Requirements and Key Design Considerations

Service discovery can be modeled as a simple query function Si = F(service-name) , where the input service-name returns a list of endpoints (ip:port) . The registry must prioritize availability (AP) over strong consistency (CP) because temporary endpoint inconsistencies are acceptable if they converge quickly.

Note: In the following text, "service" is abbreviated as "svc".

Inconsistent endpoint lists cause minor traffic imbalance, but as long as the registry converges within the SLA (e.g., 1 s), the impact is negligible. Therefore, eventual consistency is acceptable for service discovery.

CAP vs. BASE in a Registry

When a network partition occurs, a ZooKeeper‑based registry may become unavailable for writes, breaking intra‑datacenter service calls. The author stresses that a registry must never break service connectivity; it should remain available for reads even if writes are temporarily blocked.

Data Consistency Requirement

The core function is a query Si = F(service-name) returning endpoints (ip:port) . Inconsistent data leads to uneven traffic distribution, but eventual consistency mitigates this.

Partition Tolerance and Availability Requirement

In a typical three‑datacenter ZooKeeper deployment (2‑2‑1), a partition isolates one datacenter, making its nodes read‑only. This prevents new deployments, scaling, or shrinking in that zone, violating the principle that a registry must not hinder intra‑zone communication.

Service Scale, Capacity, and Connectivity

When the number of services grows to hundreds of thousands, ZooKeeper’s write throughput becomes a bottleneck. Its inability to scale horizontally for writes makes it unsuitable for high‑frequency registration and health‑check updates.

While ZooKeeper works well for coarse‑grained coordination (e.g., distributed locks), service discovery requires a registry that can handle massive write loads and provide fast, reliable reads.

Persistence and Transaction Logs

ZooKeeper persists every write via its ZAB protocol, but for service discovery the real‑time address list does not need durable storage; only metadata (version, group, weight, auth) requires persistence.

Service Health Check

Binding health to ZooKeeper session liveness is insufficient. A robust registry should allow custom health‑check logic rather than relying solely on TCP keep‑alive.

Disaster Recovery for the Registry

The registry must be weakly coupled to service calls, used only during registration, scaling, or failure events. Clients should cache snapshots and continue operating when the registry is down.

ZooKeeper Expertise Required

Operating ZooKeeper at scale demands deep knowledge of its client/session state machine and careful handling of exceptions such as ConnectionLossException and SessionExpiredException . Mis‑handling can lead to lost events or stale locks.

Conclusion

The article does not reject ZooKeeper outright but advises using it only for coordination tasks (big‑data, offline jobs) and choosing a purpose‑built, AP‑oriented service registry for large‑scale service discovery.