Eureka vs Zookeeper: AP vs CP in Service Discovery and Self‑Preservation Mode

Introduction

Eureka is an open‑source service registration and discovery product from Netflix, offering Java client wrappers. Its nodes are peer‑to‑peer and equal; the failure of some registry nodes does not affect the cluster, and even a single surviving node can continue to provide discovery services. If all registry nodes go down, Eureka clients cache service information, ensuring robust inter‑service calls.

Zookeeper, originally a sub‑project of Hadoop, provides distributed configuration, synchronization, and naming services. It is often used as a service discovery solution in many scenarios.

Comparison

In distributed systems the CAP theorem states that consistency (C), availability (A), and partition tolerance (P) cannot all be simultaneously guaranteed; at most two can be satisfied.

Zookeeper

Zookeeper follows a CP design: every request returns a consistent view of data and the system tolerates network partitions, but it cannot guarantee availability. When Zookeeper is electing a leader or a majority of its nodes are unavailable, data cannot be retrieved, so service availability suffers.

For data‑storage‑centric workloads, consistency is paramount, which explains Zookeeper’s CP orientation. However, for service discovery, strict consistency is less critical; differing node views of service instances rarely cause catastrophic failures.

For a service consumer, being able to consume (even with possibly stale data) is more important than being unable to obtain any data.

Thus, in service discovery, availability outweighs consistency—AP wins over CP.

Eureka

Spring Cloud Netflix designed Eureka according to the AP principle. Multiple Eureka Server instances can form a cluster without a master/slave distinction; they communicate via Peer to Peer peer‑to‑peer messaging. Each node registers with others, improving availability. When a server fails, clients automatically switch to another node, and the recovered node rejoins the cluster.

New Eureka nodes fetch the full registry from peers during startup, and periodic heartbeats keep the registry up‑to‑date. If a node does not receive heartbeats from a service instance within a configured timeout (default 90 seconds), it deregisters the instance. Excessive heartbeat loss triggers self‑preservation mode.

What Is Self‑Preservation Mode?

When the number of heartbeats received per minute falls below a threshold (calculated as (instance count) / (heartbeat interval seconds) ) for 15 minutes, Eureka enters self‑preservation: it stops deregistering instances to protect the registry. The mode exits automatically once heartbeat rates recover above the threshold.

The philosophy is to retain possibly erroneous registrations rather than aggressively removing healthy ones. Self‑preservation can be disabled with eureka.server.enable-self-preservation = false, and the heartbeat interval and protection coefficient can be tuned via eureka.instance.lease-renewal-interval-in-seconds and eureka.server.renewal-percent-threshold (default 0.85).

Conclusion

Zookeeper, being CP‑oriented, does not guarantee high availability; if a leader election is in progress or a majority of nodes are down, data cannot be retrieved. Eureka, built on AP, ensures high availability—clients can still obtain cached data even when all servers are down.

For a registration center whose configuration changes infrequently, AP is more suitable because it can sacrifice consistency to maintain availability, returning stale or cached data when necessary. In practice many projects still use Zookeeper because clusters are often small and the risk of a majority of nodes failing is low, so the CP trade‑off is acceptable.