6.3. Service Discovery

In a dynamic environment where instances start, stop, and move constantly, hard-coded addresses are impossible — a service must discover where its dependencies currently live. The core choice is where that lookup happens: client-side discovery puts the logic (and the load-balancing decision) in the caller, server-side hides it behind a load balancer. This chapter covers both models, the registration approaches that keep the registry accurate, and the health-check pattern that ensures discovery never returns a dead instance.

Topics Covered

• 6.3.1. Client-Side Discovery: Eureka, Ribbon, and Spring Cloud LoadBalancer: Covers client-side discovery with Eureka, Ribbon, and Spring Cloud LoadBalancer, where the caller picks the instance.
• 6.3.2. Server-Side Discovery: Load Balancer + Registry: Explains server-side discovery, hiding instance selection behind a load balancer and registry.
• 6.3.3. Self-Registration vs. Third-Party Registration: Compares services registering themselves against a third-party registrar handling registration.
• 6.3.4. Consul: Service Discovery + Health Checking + KV Store: Covers Consul’s combined service discovery, health checking, and key-value store.
• 6.3.5. DNS-Based Discovery: Kubernetes DNS: Explains DNS-based discovery and how Kubernetes DNS resolves services to cluster-internal addresses.
• 6.3.6. Health Check Endpoint Pattern: Covers the health-check endpoint pattern that lets discovery and load balancers avoid dead instances.