Why it matters

Wrong service discovery choice creates coupling or fragility. Getting it right lets services scale and evolve independently. This is core microservices infrastructure.

Advertisement

The architecture

DNS-based: services register in DNS; clients resolve service name to IP. Simple, ubiquitous. TTL caching can cause staleness.

KV-store based: Consul, etcd, ZooKeeper. Services register with health checks; clients query for healthy instances. Rich metadata support.

Service discovery optionsDNSsimple, TTL-limitedConsul/etcdKV + healthK8s Servicescluster-integratedK8s Services combine DNS with cluster-native health; simplest for K8s deployments
Discovery mechanisms.
Advertisement

How it works end to end

Kubernetes Services: cluster-native. Services get stable virtual IP; kube-proxy load-balances to pods. Selector-based membership updates automatically.

Client-side vs server-side: client-side (clients cache full service list, choose backend) — richer routing but complex. Server-side (client hits LB or virtual IP) — simple but less flexible.

Service mesh (Istio, Linkerd) adds discovery + routing + mTLS + observability. Runs a sidecar per service.