How Service Registries Enable Dynamic Addressing in Distributed Systems

Hard‑coding service endpoints causes connection timeouts when instances change; a service registry provides automatic addressing.

Step 1 – Service registration and discovery

When a provider starts it registers its IP, port and metadata (e.g., version, weight) with the registry. The registry maintains a list of addresses. A consumer subscribes to the desired service; the registry pushes the current address list. The consumer selects a node via a load‑balancing algorithm (round‑robin, random, weighted). When instances are added or removed, the registry pushes updates instantly, keeping the address list dynamic without code changes.

Step 2 – Heartbeat detection

Each registered instance sends a heartbeat at a fixed interval (e.g., 5 seconds). The registry marks an instance dead after missing three consecutive heartbeats. Timeout = heartbeat_interval × 3. The factor three balances network jitter and GC pauses against detection latency.

Network partition can drop all heartbeats. A cited case: Redis replication delay caused the registry to treat every node as timed‑out, resulting in a full outage. The registry’s self‑protection mechanism pauses removal when more than 40 % of instances become unreachable and raises an alert, preferring to keep possibly stale nodes rather than empty the service list.

Step 3 – Registry selection matrix

Nacos (Alibaba open‑source): combines registry and configuration center; supports AP mode for discovery (Distro protocol) and CP mode for configuration (Raft). Widely used by Chinese Java teams; integrates with Spring Cloud Alibaba; provides a console.

Eureka (Netflix): pure AP model; simple architecture; 2.x line no longer maintained; suffers from “ghost instances” that are hard to evict. Suitable for legacy projects, not recommended for new ones.

ZooKeeper : CP model, primarily a coordination service (leader election, locks). Registry functionality is secondary; during leader election half the cluster may be unable to fetch the service list. If a project already relies on ZooKeeper for coordination, a hybrid approach (ZooKeeper for coordination + Nacos for registry) is suggested.

ETCD : CP model, underlying store for Kubernetes. In Kubernetes‑centric environments, K8s Service + ConfigMap often suffices; ETCD is added only when stronger consistency is required.

Selection guideline: Chinese Java teams tend to choose Nacos; Kubernetes‑centric stacks favor ETCD; multi‑language systems needing strong consistency may opt for Consul; avoid migrating legacy Eureka projects unless necessary.

Summary framework

Discovery solves “where does the address come from”: services register themselves, changes are pushed in real time, callers remain oblivious to node churn.

Heartbeat solves “is the address trustworthy”: periodic heartbeats, three‑times timeout, and a 40 % self‑protection line provide sensitivity without false positives.

Selection solves “which registry to use”: choose based on tech stack, consistency requirements, and ecosystem compatibility; no universal silver bullet.