Topic 11.4
Service Discovery
In one line
Finding a service instance by NAME, not IP: registry + heartbeats, or DNS-based resolution.
Think of it like this
A company's internal phone directory. Instead of memorizing everyone's desk phone number (which changes when people move desks), you look them up by name in the directory and always get their current number.
Key ideas
- 01
Problem: instances come and go — clients can't hardcode IPs.
- 02
Client-side discovery: registry (Consul/Eureka/metadata) → client picks an instance (Ribbon-style).
- 03
Server-side discovery: LB queries the registry and routes (K8s Service, cloud LB).
- 04
Kubernetes story: Service name → DNS → endpoints → instances; health probes (liveness/readiness) keep the list honest.
- 05
Heartbeats vs probes: instances register + renew leases; the registry evicts after missed heartbeats.
- 06
Interview: 'service discovery by name via the platform (K8s/Consul); readiness gates gate the traffic'.
Java / Spring map
- →
Spring Cloud: @EnableDiscoveryClient + LoadBalanced RestTemplate → resolves name→instances automatically.
Code & diagrams
Instances register themselves; nobody hardcodes an IP anywhere.
Explain without notes
What happens during a rolling deploy when pods are terminating — and what makes the LB stop sending traffic?
Practice
Sketch discovery: registry, register, heartbeat, evict, and the client round-robin over live instances.
Trade-offs
- ↔
Registry = consistency point (needs HA/quorum); DNS=7 TTL-lag; K8s hides both behind the platform.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can describe discovery without IPs and name the health signal that protects it.