Which Service Registry Should You Choose? A Deep Dive into Zookeeper, Eureka, Nacos, Consul, and Etcd

Registry Basics

A service registry plays three roles: the service provider registers its address and sends heartbeats, the service consumer subscribes to the registry and caches the address list, and the registry itself stores and synchronizes service metadata across nodes.

CAP Theory

Consistency : all nodes see the same data at the same time.

Availability : every request receives a response, success or failure.

Partition tolerance : the system continues operating despite network partitions.

The article explains why only two of the three properties can be guaranteed simultaneously and illustrates the trade‑offs for service discovery.

Distributed Consensus Algorithms

The article lists Paxos, Raft and ZAB as the main consistency protocols. Paxos requires a majority of replicas to be online, Raft simplifies Paxos for easier implementation, and ZAB is a ZooKeeper‑specific adaptation of Paxos designed for crash recovery.

Individual Registries

Zookeeper

Zookeeper stores service information as znodes such as /HelloWorldService/1.0.0/100.19.20.01:16888. It provides a watch mechanism that pushes lightweight change events to clients, which then pull the actual data. The article notes that Zookeeper follows a CP model, offering strong consistency but suffering from long leader‑election pauses (30‑120 s) that can make the registry unavailable.

Eureka

Eureka adopts an AP model: as long as any Eureka instance is alive, service registration remains available, though the data may be stale. It uses a peer‑to‑peer architecture, automatic instance registration, heartbeat‑based expiration (default 90 s), and a self‑protection mode that disables deregistration when >85 % of heartbeats are missing.

Nacos

Nacos, an Alibaba open‑source project, supports both CP and AP modes, DNS‑based and RPC‑based discovery, health checks, dynamic configuration, and a UI for managing services. The article quotes the official Nacos documentation for its feature set.

Consul

Consul is a Go‑based tool that uses the Raft algorithm (CP) for strong consistency. It provides service registration, health checks, KV storage, multi‑data‑center support, TLS certificates, and both HTTP and DNS APIs. The article describes Consul’s client/server roles, gossip‑based membership, and port usage (8300‑8302).

Etcd

Etcd is a Go‑written, HTTP + JSON API key‑value store that uses Raft for strong consistency. It offers easy deployment, high availability, WAL‑based persistence, snapshots, and supports up to 10 K QPS writes. The internal architecture consists of an HTTP server, a Store layer, the Raft module, and WAL for durability.

Comparison and Selection

Health checks : Eureka requires explicit configuration; Zookeeper and Etcd rely on connection loss; Consul provides detailed metrics.

Multi‑data‑center support : Consul and Nacos have built‑in support; others need custom work.

KV storage : All except Eureka expose a KV API, enabling dynamic configuration.

CAP trade‑offs : Eureka (AP) and Nacos (configurable) favor availability; Zookeeper, Etcd, Consul (CP) favor consistency.

Watch mechanism : Zookeeper pushes change events; others use long‑polling.

Metrics and monitoring : Zookeeper and Nacos expose metrics by default; the rest provide optional metrics.

Spring Cloud integration : All have corresponding boot starters.

For selection, the author recommends choosing AP‑oriented registries (Eureka or Nacos) when high availability outweighs strict consistency, and considering the technology stack (Java‑based vs Go‑based) and community activity.