Architecture
Service Discovery
How services find each other's dynamic network locations in an environment where instances constantly come and go — via a registry (Consul, Eureka) or platform DNS (Kubernetes), with health checks removing dead nodes. It becomes essential once you scale horizontally behind autoscalers. Without it you hardcode addresses that break on every deploy.
Purpose
Service discovery answers 'where is the orders service right now?' in environments where instances scale up, die and move constantly. A registry tracks live instances and their addresses; clients or load balancers resolve through it instead of hardcoding hosts.
When to Use It
Any horizontally scaled or orchestrated system: autoscaling groups, Kubernetes, service meshes. In Kubernetes it is built in — a Service name resolves via cluster DNS to healthy pods — which is why many teams never operate a discovery system directly.
Trade-offs
A registry is critical infrastructure: if discovery is down, everything is down, so it must be replicated and consistent. Health-check tuning is the subtle part — too aggressive and healthy nodes flap out; too lax and traffic keeps hitting the dead.
Implementation
On a platform, lean on the built-ins (Kubernetes Services/DNS). Otherwise run a registry such as Consul: services register on start, heartbeat while alive, and are evicted when checks fail; clients resolve through DNS or a local sidecar. Always pair discovery with health checks — an address list without liveness is worse than useless.