service-discovery

To find healthy service instances in dynamic fleets, you query a service registry using client-side or server-side discovery, which filters out dead endpoints based on active health checks. This returns a live list of available nodes for connection.

Connection refused errors and 503 responses after deployments often happen because clients or load balancers hold stale IPs from cached service instances. Propagating health-check updates through a service registry removes dead hosts from the active pool.

Client-side service discovery lets clients directly query a registry to select healthy instances via local caching, while server-side discovery delegates instance selection to a load balancer acting on the client's behalf.

Yes, this service discovery approach supports Consul, etcd, and Kubernetes. It integrates with these registries to retrieve healthy instances using mechanisms like DNS or direct API queries.

To handle stale IPs in local cache during dynamic scaling, implement client-side service discovery with active health-check propagation. This ensures your local cache automatically receives updates and removes unreachable instances.

Yes, you need a service registry and proper client configuration to perform service discovery. The registry stores instance locations, while health checks ensure the returned endpoints are actually alive and ready for traffic.