What is service discovery and why is it needed?
Assesses fundamental understanding of Microservices conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
In a dynamic environment, service instances start, stop and move, so callers cannot rely on fixed hostnames. Service discovery maintains a registry of healthy instances and lets clients resolve a logical service name to a live address.
Two patterns:
- Client-side discovery: the caller queries the registry (Consul, Eureka) and load-balances itself. Fewer hops but discovery logic in each client.
- Server-side discovery: the caller hits a load balancer or virtual IP, and the platform (Kubernetes Services, cloud load balancers) routes to a healthy instance. Simpler clients, one extra hop.
# Kubernetes resolves this name to ready pods
http://order-service.default.svc.cluster.local
Health checks are essential so unhealthy instances are removed quickly. In Kubernetes, DNS plus a Service is built-in discovery; for VMs you typically need a registry. Combine discovery with retries, timeouts and circuit breakers so a stale address does not cascade into an outage.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.