Which Service Registry Should You Choose? Zookeeper, Eureka, Nacos, Consul, or Etcd

Registry Basics

A service registry mediates three roles:

Service Provider (RPC server) registers its name, IP and port at startup and sends periodic heart‑beats.

Service Consumer (RPC client) queries the registry, caches the returned node list and uses it for RPC calls, refreshing the cache when notified.

Registry stores registration data, watches for node changes and pushes notifications to consumers.

Clients then apply a load‑balancing algorithm to select a target server from the cached list.

Required Functions

Service registration and deregistration

Health checking (heartbeat or connection loss detection)

Watch/notification mechanism

Leader election for a single authoritative node

Persistent storage of registration data

Fundamental Theory

CAP Theorem

In a distributed system only two of Consistency (C), Availability (A) and Partition tolerance (P) can be guaranteed simultaneously.

Consistency : all nodes see the same data at the same logical instant.

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

Partition tolerance : the system continues operating despite network partitions.

Choosing C first forces the system to perform data synchronization, which adds latency and reduces A. Choosing A first permits stale reads. Achieving both C and A while tolerating partitions is infeasible without sacrificing one of the other properties.

Distributed Consensus Algorithms

Typical algorithms are Paxos, Raft and ZooKeeper Atomic Broadcast (ZAB).

Paxos (Lamport, 1990) requires a majority of replicas to be online; it guarantees no data loss but is notoriously complex.

Raft (Ongaro & Ousterhout) was designed for understandability; it also needs a majority of nodes and is the consensus layer of etcd and Kubernetes.

ZAB is a ZooKeeper‑specific adaptation of Paxos that adds crash‑recovery‑oriented atomic broadcast.

Common Registries

Zookeeper

Although not marketed as a registry, Zookeeper is widely used by Dubbo for service discovery.

When a provider starts it creates a znode such as /HelloWorldService/1.0.0/100.19.20.01:16888. A second instance creates a sibling znode under the same parent. Consumers set a watch on the parent path; Zookeeper sends a lightweight event (the watch) and the client pulls the updated list.

Limitations:

Leader election can take 30‑120 seconds; during this window the whole cluster is unavailable, which is unacceptable for high‑availability service discovery.

Zookeeper follows a CP model (strong consistency) and therefore sacrifices availability when a partition occurs.

Eureka

Eureka implements the AP principle: as long as at least one Eureka node is reachable, service lookup works, though the data may be stale.

Peer‑to‑peer architecture; no master/slave distinction.

Automatic client‑side failover.

Heartbeat interval: 30 s (default). Lease expiration: 90 s (configurable via eureka.instance.lease-expiration-duration-in-seconds).

Self‑protection mode triggers when >85 % of heartbeats are missing for 15 min, preventing mass deregistration.

Typical workflow:

Eureka Server starts and waits for registrations.

Clients register their instances.

Clients send a heartbeat every 30 s.

If a server misses heartbeats for 90 s it deregisters the instance.

When many heartbeats are missing the server enters self‑protection and stops deregistering.

When heartbeats resume the server exits self‑protection.

Clients periodically pull the full or incremental registry and cache it locally.

Service calls first consult the local cache; a cache miss triggers a refresh from the server.

Clients deregister on graceful shutdown.

Eureka’s design favors availability, making it suitable for multi‑data‑center deployments where occasional staleness is tolerable.

Nacos

Excerpt from the official Nacos documentation: https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos provides service discovery, health monitoring, dynamic configuration and DNS‑based routing. It can operate in both CP and AP modes, effectively combining the functions of a Spring Cloud Service Registry and Config Center.

Health checks: TCP/PING or application‑level probes; supports both agent‑reporting and server‑initiated checks.

Dynamic configuration: version tracking, canary releases, one‑click rollback, UI for management.

Dynamic DNS: weighted routing, internal DNS resolution, simple API for managing service domains.

Consul

Consul (HashiCorp) is an all‑in‑one solution offering service discovery, health checks, a KV store and multi‑data‑center support.

Strong consistency via Raft (CP); availability is not guaranteed during partitions.

Health checks run every 10 s by default.

Provides both HTTP and DNS APIs.

Gossip protocol maintains membership; leader election among 3‑5 server nodes.

Metrics are exposed for monitoring.

Typical registration flow (simplified):

Producer sends a POST with its IP:port to Consul.

Consul performs a health check every 10 s.

Consumer queries /api/address; Consul returns a temporary table of healthy producers.

The table is refreshed every 10 s, containing only instances that passed health checks.

Etcd

Etcd is a Go‑based distributed key‑value store built on Raft, offering strong consistency, high availability and up to 10 K QPS write throughput.

HTTP Server : handles API requests and inter‑node communication.

Store : implements transactions, indexing and event handling.

Raft : core consensus module.

WAL : write‑ahead log for durability; snapshots prevent unbounded log growth.

Request flow: client → HTTP Server → Store → (if state‑changing) Raft replication → commit → optional snapshot.

Comparison & Selection

Feature Matrix

Health Check : Eureka requires explicit config; Zookeeper/Etcd rely on lost connections; Consul provides detailed metrics (memory, disk, etc.).

Multi‑Data‑Center : Consul and Nacos support it out‑of‑the‑box; others need custom integration.

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

CAP Trade‑off : Eureka (AP) and Nacos (configurable) prioritize availability; Zookeeper, Etcd and Consul (CP) prioritize consistency.

Watch Support : Zookeeper pushes events; others use long‑polling or periodic pulls.

Metrics : Zookeeper and Nacos need extra setup; Consul, Eureka, Etcd expose built‑in metrics.

Spring Cloud Integration : All provide a boot starter for seamless use.

Selection Guidance

CAP Preference : Choose an AP solution (Eureka, Nacos) when availability outweighs consistency.

Technology Stack : Go‑centric projects often adopt Etcd or Consul; Java‑centric ecosystems tend toward Zookeeper, Eureka or Nacos.

High Availability : All projects support HA clusters; compare election latency (e.g., Zookeeper’s 30‑120 s leader election vs. Raft’s sub‑second failover in Consul/Etcd).

Project Activity : All listed open‑source projects are actively maintained, so community support and release cadence are comparable.

By analysing the consistency vs. availability trade‑off, ecosystem compatibility, operational features (health checks, KV store, multi‑data‑center support) and performance characteristics (election latency, QPS limits), engineers can select the registry that best fits their microservice architecture.