Service Discovery: Call Patterns, Consistency Trade‑offs, and Health‑Check Designs

When microservice systems grow, static configuration cannot meet requirements such as dynamic scaling, rapid node changes, multi‑zone deployment, and enriched node metadata, prompting the need for a dedicated service discovery system.

Two main call patterns are presented: client‑side discovery, exemplified by Netflix Eureka and Ribbon, where the client queries a registry and performs load balancing locally; and server‑side discovery, illustrated by Kubernetes kube‑proxy, which acts as a reverse proxy tightly integrated with the registry and hides discovery details from the client.

The article then explores consistency trade‑offs using the CAP theorem, contrasting CP systems (e.g., Consul, Zookeeper, Etcd) that guarantee strong consistency but sacrifice availability, with AP systems (e.g., Eureka) that provide eventual consistency to maximize availability.

Health‑check mechanisms are categorized into client‑initiated heartbeats (TCP/HTTP or long‑lived sockets) and server‑initiated active probes (HTTP endpoints, RPC calls, or script execution), highlighting their advantages and limitations.

Graceful service up/down procedures are described, including health‑check‑based registration, callback‑based registration, and signal‑driven deregistration combined with graceful shutdown or delayed exit to allow in‑flight requests to complete.

High‑availability considerations cover distributed storage of node information, protection modes for partial or total registry failures, network‑partition handling, and client SDK strategies for node exclusion, retry back‑off, and fallback to cached data.

Finally, the article advises on metadata design for service registration, recommending a balance between essential information (service name, IP, port) and optional attributes (protocol, tags, weight) to avoid performance degradation.