Microservices Service Discovery Interview Questions and Answers

In a microservices system, instances start, stop, scale, and move constantly, so their network addresses are not stable — which makes "how does service A find service B?" a genuine problem rather than a config line. Service discovery interviews check that you understand the registry, the two discovery models, and how the system avoids sending traffic to instances that have died. This page walks through the questions asked on the topic and the resilience follow-ups that matter.

Why can't services just use hardcoded IP addresses?

Because instances are ephemeral — they get new IPs on every deploy, autoscaling adds and removes them, and container schedulers move them across hosts. Hardcoding addresses breaks the moment anything changes, which in a dynamic environment is constantly.

Service discovery replaces static configuration with a live lookup: services announce where they are, and callers ask for the current location of a healthy instance. This is the foundation that makes elastic scaling and rolling deployments possible.

What is a service registry and how does it stay current?

A registry is a live directory of available instances and their addresses. Instances register on startup, deregister on graceful shutdown, and send periodic heartbeats; if heartbeats stop, the registry marks the instance down and stops returning it. Eureka, Consul, and etcd are typical registries.

The key property is that the registry is eventually consistent. There is always a small window where a just-died instance is still listed, which is exactly why callers also need retries and circuit breakers — discovery reduces bad routing but cannot eliminate it instantly.

Interview note: Follow-up: "what happens between an instance dying and the registry noticing?" Callers may briefly get a dead address — they must retry against another instance. Discovery and resilience patterns work together, never alone.

Client-side vs server-side discovery — explain the difference.

Client-side: the caller queries the registry itself, receives the list of instances, and applies its own load-balancing logic to pick one. Server-side: the caller sends the request to an intermediary (load balancer or gateway) that consults the registry and forwards it, so the client stays dumb.

Client-side (classic Netflix Eureka + Ribbon/Spring Cloud LoadBalancer) gives clients fine control and removes an extra hop, but every client — potentially in multiple languages — must implement discovery. Server-side (a gateway, a Kubernetes Service, AWS ELB) centralizes the logic and keeps clients simple, at the cost of an extra network hop and a component to operate.

Interview note: Trap: "which is better?" Depends on your platform. On Kubernetes, server-side via DNS is the default and you rarely add Eureka. In a Spring Cloud stack without a mesh, client-side is common.

Show how a service registers and discovers others.

A service registers with the registry on startup and, for client-side discovery, a discovery-aware client resolves a logical service name to a live instance before each call.

// Client-side discovery: call by logical service name, not host:port
@LoadBalanced           // enables discovery + load balancing on this RestClient
@Bean
RestClient.Builder restClientBuilder() { return RestClient.builder(); }

// usage — "inventory-service" is resolved to a healthy instance at call time
inventory = restClient.get()
    .uri("http://inventory-service/api/stock/{sku}", sku)
    .retrieve()
    .body(Stock.class);

The logical name inventory-service never changes even as instances churn — the registry maps it to a real address at call time. That indirection is the entire point of discovery.

How do health checks fit into discovery?

Health checks let the registry (or platform) verify an instance is actually able to serve traffic, not just running. An instance failing its health probe is removed from the pool so no traffic is routed to it. Heartbeats prove liveness; health checks prove readiness to serve.

Distinguishing liveness (the process is up) from readiness (it can handle requests — dependencies connected, warm-up done) is a detail that reads as real Kubernetes experience. A pod can be alive but not ready during startup, and discovery must respect that.

How does service discovery work on Kubernetes?

Kubernetes provides discovery natively: every Service object gets a stable DNS name and cluster IP, and kube-proxy load-balances requests to the healthy pods selected by that Service. Applications just call http://orders-service and the platform handles resolution and balancing.

Because of this, teams on Kubernetes usually drop a separate registry like Eureka — the platform is the registry. Bringing that up shows you know discovery is often infrastructure, not application code, in modern deployments.

Interview note: Follow-up: "how does Kubernetes know which pods are healthy?" Readiness probes — a pod failing its readiness probe is removed from the Service's endpoints and receives no traffic.

What happens if the registry itself goes down?

A single registry is a critical dependency, so it runs as a replicated cluster, and clients cache the last known instance list so they can keep routing during a brief registry outage. Eureka clients, for example, keep a local cache and degrade gracefully rather than failing instantly.

This is a favorite resilience question: the discovery layer must not be a single point of failure, so you replicate it and design clients to tolerate its temporary unavailability.

How is a self-registering service different from third-party registration?

Self-registration: the service registers and deregisters itself with the registry. Third-party registration: a separate registrar component watches the platform and registers instances on their behalf. Kubernetes uses the third-party model — you never write registration code; the control plane manages endpoints as pods come and go.

What interviewers really test

Service discovery questions check whether you understand that addresses in microservices are dynamic and that the system must tolerate the lag between reality and the registry. Strong candidates connect discovery to resilience — stale entries, retries, replicated registries — and know that on Kubernetes discovery is DNS, not a library. Be ready to compare client-side and server-side with a concrete stack.

Discovery, load balancing, and the gateway form one story, so pair this with the load balancing questions and the API gateway question set. Build the underlying model with the microservices learning path, and use a mock interview to practice explaining a discovery flow end to end without hand-waving.