Service Discovery

In Kubernetes, Docker Swarm, or any auto-scaling environment, service instances come and go. Hard-coding http://inventory-service:8080 breaks the moment a container restarts on a different port or IP. Service discovery solves this with a registry: each instance registers itself on startup ("I am inventory-service, version 2.1, at 10.0.4.12:8080, healthy") and deregisters on shutdown.

Clients — or an API Gateway, or a service mesh sidecar — query the registry to find a healthy instance before each request. Kubernetes DNS (inventory-service.default.svc.cluster.local) is a built-in form of service discovery. Consul, Eureka, and etcd are standalone registries used outside Kubernetes or for multi-cluster setups.

Before

Hard-coded endpoint

1const INVENTORY_URL = 'http://10.0.4.12:8080';2 3async function checkStock(productId: string) {4  return fetch(`${INVENTORY_URL}/stock/${productId}`);5}6// Breaks when the container moves or scales

After

Discovery lookup (pseudo-code sketch)

1async function checkStock(productId: string) {2  const instance = await registry.getHealthy('inventory-service');3  return fetch(4    `http://${instance.host}:${instance.port}/stock/${productId}`5  );6}7// Registry returns any healthy instance

Check your understanding

Why do hard-coded IPs fail in orchestrators?Show answerHide answer
Answer
Instances restart with new IPs/ports; discovery or DNS must track healthy endpoints.
What does registry.getHealthy represent in the sketch?Show answerHide answer
Answer
Pseudo-code for looking up a healthy instance — real systems use DNS, a client library, or a mesh sidecar.
Name a built-in Kubernetes discovery mechanism.Show answerHide answer
Answer
Service DNS (e.g. inventory-service.default.svc.cluster.local).