What is Service Discovery in Microservices?
Learn what service discovery is, client-side vs server-side patterns, health checking, and tools like Consul and Kubernetes.
Expected Interview Answer
Service discovery is the mechanism by which services in a distributed system automatically find the current network location of other services, since instances scale, restart, and move IP addresses constantly in a way that hardcoded addresses cannot keep up with.
In a client-side discovery pattern, a caller queries a service registry directly to get a list of healthy instance addresses and then picks one itself, often with a load-balancing strategy baked into the client library. In a server-side discovery pattern, the caller sends its request to a well-known load balancer or gateway, which queries the registry on the caller’s behalf and forwards the request, keeping discovery logic out of every client. Instances register themselves with the registry on startup (self-registration) or are registered by an external agent (third-party registration), and the registry continuously health-checks entries so dead instances are removed automatically. Tools like Consul, etcd, and Kubernetes’s built-in DNS-based service discovery (backed by kube-proxy and Endpoints) implement this pattern, letting services address each other by stable logical names instead of ephemeral IPs.
- Lets services address each other by stable logical name instead of ephemeral IP
- Automatically removes unhealthy or crashed instances from routing decisions
- Enables horizontal autoscaling since new instances are discoverable the moment they register
- Decouples deployment topology from application code, simplifying rolling deploys
AI Mentor Explanation
Service discovery is like a team’s dressing-room whiteboard that lists which substitute is currently on the field and their exact fielding position, updated the moment a swap happens. Instead of a bowler memorizing a fixed position for the wicketkeeper, they glance at the board to find whoever is currently there, because injuries and rotations change who’s on the field constantly. If a fielder leaves injured, the board is updated immediately so no one throws the ball to an empty spot. That live, always-current lookup of who’s actually available is exactly what a service registry provides between microservices.
Step-by-Step Explanation
Step 1
Instance registers itself
On startup, a service instance registers its address (and health-check endpoint) with the service registry, either directly or via a sidecar/agent.
Step 2
Registry health-checks continuously
The registry pings each registered instance on an interval and removes any that stop responding.
Step 3
Caller resolves the logical name
A client (or its client-side load balancer) queries the registry for healthy instances behind a logical service name.
Step 4
Request is routed to a live instance
The caller (client-side pattern) or a load balancer (server-side pattern) picks one healthy instance and sends the request.
What Interviewer Expects
- Distinguishes client-side vs server-side discovery patterns clearly
- Explains self-registration vs third-party registration of instances
- Mentions health checking as core to removing dead instances automatically
- Names real tools: Consul, etcd, Kubernetes DNS/Endpoints, Eureka
Common Mistakes
- Confusing service discovery with plain DNS with no health checking
- Forgetting that instances must be removed automatically when they become unhealthy
- Not distinguishing where the load-balancing decision is made (client vs server side)
- Assuming service discovery is only relevant to Kubernetes, ignoring Consul/etcd-based setups
Best Answer (HR Friendly)
“Service discovery is how one part of a system finds another part when servers are constantly starting, stopping, and changing addresses. Instead of hardcoding an IP address, a service asks a registry, 'where is the payments service right now?' and gets back a live, healthy address to talk to. This is essential in cloud environments where instances scale up and down automatically.”
Code Example
apiVersion: v1
kind: Service
metadata:
name: payments-service
spec:
selector:
app: payments
ports:
- port: 80
targetPort: 8080
# other pods reach this via DNS name “payments-service”
# kube-proxy + Endpoints keep the backing pod IPs updated automatically
---
apiVersion: v1
kind: Pod
metadata:
name: payments-7f9c
labels:
app: payments
spec:
containers:
- name: payments
image: payments:v3
readinessProbe:
httpGet:
path: /healthz
port: 8080Follow-up Questions
- What is the difference between client-side and server-side service discovery?
- How does Kubernetes implement service discovery under the hood?
- What happens if the service registry itself becomes unavailable?
- How does service discovery relate to a service mesh like Istio or Linkerd?
MCQ Practice
1. In client-side service discovery, who decides which healthy instance to call?
In client-side discovery, the caller queries the registry directly and picks an instance itself, often with built-in load balancing.
2. What removes a crashed instance from being routed to in a healthy service discovery setup?
The registry actively health-checks registered instances and deregisters ones that stop responding.
3. Which of these is a real service discovery / registry tool?
Consul is a widely used service discovery and configuration tool; the others are unrelated build/design tooling.
Flash Cards
What is service discovery? — The mechanism services use to automatically find the current network location of other services.
Client-side vs server-side discovery? — Client-side: caller queries the registry and picks an instance. Server-side: a load balancer queries the registry on the caller's behalf.
Why is health checking essential? — It removes crashed or unresponsive instances from the registry so requests are never routed to dead endpoints.
Name a service discovery tool. — Consul, etcd, or Kubernetes's built-in DNS-based service discovery.