communication
Service Discovery
Let services find each other dynamically without hard-coded hostnames — so instances can scale and move freely.
In a microservices system running on containers and autoscalers, service instances come and go constantly — they scale up and down, get rescheduled onto different hosts, and are replaced on every deploy. Their IPs and ports are not stable, so hard-coding an endpoint like http://10.0.1.5:8080 breaks the moment the target moves. Service discovery is the mechanism that lets a service find a healthy instance of another by logical name, dynamically, without anyone editing configuration.
A phone directory that updates itself: you look people up by name and always get their current number, even though people move house constantly.
Key Concepts
1
The heart of it is a service registry — a constantly-updated directory mapping service names to the network locations of their currently-healthy instances. Instances register themselves on startup (and deregister on shutdown), and the registry health-checks them so dead instances are removed. Consumers then resolve a name like orders-service to a live address at call time. There are two architectural styles. In client-side discovery, the caller queries the registry and picks an instance itself, often load-balancing across them (Netflix Eureka with Ribbon is the classic example). In server-side discovery, the caller just hits a stable load balancer or DNS name and the platform routes to a healthy instance behind it — which is how Kubernetes works, where a Service provides a stable virtual IP and DNS name in front of a churning set of pods, so application code never touches a registry directly.
orders-service
2
The points interviewers look for are why discovery is necessary (the impossibility of static endpoints in an elastic environment), the client-side versus server-side trade-off (client-side gives smart load balancing but couples clients to the registry; server-side keeps clients simple but adds a network hop), and how health checking keeps the registry honest. On modern platforms the practical answer is often "the orchestrator does it" — Kubernetes DNS and Services — which is itself a form of server-side discovery worth naming.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "Why is a hardcoded host list not enough?" *Probing:* the motivating problem. *Stalls:* "It
works." *Moves up:* instances come and go with scaling and deployment, so the address list is stale
minutes after you write it.
1. "Why is a hardcoded host list not enough?"
5
2. "What is the difference between client-side and server-side discovery?" *Probing:* the two
models. *Stalls:* "Nothing." *Moves up:* client-side asks the registry and picks an instance itself;
server-side goes through a load balancer that does the lookup.
2. "What is the difference between client-side and server-side discovery?"
6
3. "How does an instance leave the registry cleanly?" *Probing:* the lifecycle. *Stalls:* "It is
removed." *Moves up:* deregistration on shutdown plus health checks with a TTL, so a crashed
instance ages out rather than receiving traffic.
3. "How does an instance leave the registry cleanly?"
7
4. "What does Kubernetes change here?" *Probing:* currency. *Stalls:* "Nothing." *Moves up:*
DNS-based service discovery is built in, so a separate registry is usually unnecessary on that
platform.
4. "What does Kubernetes change here?"