Overview
Service discovery is how services find the network locations of other services in dynamic environments where instances start, stop, and move constantly. Instead of hard-coded IP addresses, services register themselves in a registry (or the platform does it for them), and clients look up healthy instances by name.
There are two styles. Client-side discovery: the client queries the registry and load balances itself (Netflix Eureka, Consul with client libraries). Server-side discovery: the client calls a stable name or load balancer that routes to healthy instances (Kubernetes Services and DNS, AWS Cloud Map with load balancers, service meshes).
Instead of memorizing everyone's desk phone (which changes when they move), you look up people by name in a directory that is updated whenever someone moves desks or goes home.
When to use it
- Microservices with autoscaling and frequent deployments.
- Hybrid environments where services span clusters or VMs.
- Health-aware routing to only healthy instances.
- Multi-region or multi-cluster service lookups.
Where it shows up in interviews
Recognize it when: how does service A find service B?
- Design a microservices platform
- Design inter-service communication on Kubernetes
Where it is used in real software
Every Service gets a DNS name like orders.prod.svc.cluster.local that resolves to a stable virtual IP.
Service registry with health checks, DNS and HTTP APIs, and multi-datacenter support.
Client-side discovery used with Ribbon load balancing in the Spring Cloud ecosystem.
Key terms
- Service registry
- Database of service instances and their health.
- Registration
- Instances or the platform add entries on startup.
- Health check
- Removes unhealthy instances from results.
- Client-side vs server-side discovery
- Client picks the instance vs a router picks it.
- Service mesh
- Sidecar proxies handle discovery, routing, and security.
How it works, step by step
- 1Instance starts
Registers name, address, port, and metadata.
- 2Health checks run
Registry marks instances healthy or not.
- 3Client resolves the name
Via DNS, API, or a local proxy.
- 4Traffic goes to a healthy instance
Load balanced by client or proxy.
- 5Instance stops
Deregisters, or expires when heartbeats stop.
Discovery approaches
How clients find orders-service
| Approach | Client does | Examples | Trade-off |
|---|---|---|---|
| DNS-based | Resolve a name | Kubernetes DNS, Route 53, Cloud Map | Simple; DNS caching delays updates |
| Server-side LB | Call a stable VIP | Kubernetes Service, ALB | Extra hop; clients stay simple |
| Client-side registry | Query registry, pick instance | Eureka, Consul | Smart clients per language |
| Service mesh | Call localhost proxy | Istio, Linkerd | Powerful; adds sidecars and complexity |
NOWApproach: DNS-based | Client does: Resolve a name | Examples: Kubernetes DNS, Route 53, Cloud Map | Trade-off: Simple; DNS caching delays updates
On Kubernetes, built-in Services and DNS cover most needs; meshes add mTLS and advanced routing.
Implementation
# Orders pods are discoverable at http://orders.shop.svc.cluster.local (or just http://orders within the namespace)apiVersion: v1kind: Servicemetadata: { name: orders, namespace: shop }spec: selector: { app: orders } # only Ready pods with this label receive traffic ports: [{ name: http, port: 80, targetPort: 8080 }]---# Headless service: DNS returns individual pod IPs (for client-side balancing or StatefulSets)apiVersion: v1kind: Servicemetadata: { name: orders-headless, namespace: shop }spec: clusterIP: None selector: { app: orders } ports: [{ port: 8080 }]Complexity and performance
Microseconds to ms.
Health checks and DNS TTL.
Trade-offs
Client-side avoids an extra hop and enables smart balancing but needs libraries in every language; server-side keeps clients simple.
DNS works everywhere but caching can route to dead instances briefly.
Variants and related techniques
Mesh federation or Cloud Map across clusters and regions.
Static config for small, stable systems.
Common mistakes
- Hard-coding IP addresses.
Fix: Always use names from discovery.
- Long DNS caching in clients.
Fix: Respect TTLs; the JVM may cache DNS forever by default.
Interview questions
How do microservices find each other on Kubernetes?
Each Service gets a stable DNS name and virtual IP; kube-proxy or the CNI routes connections to Ready pods matching the selector, so clients call http://orders without knowing pod IPs.
Client-side vs server-side discovery?
Client-side: the client fetches instances from a registry and load balances itself. Server-side: the client calls a load balancer or proxy that queries the registry and routes the request.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Expose a service internally on Kubernetes | Easy | Services and DNS. |
| Design discovery across two clusters | Hard | Federation. |