Lesson 26 of 30

Service Discovery & DNS in Container Networks

Q: A service you're calling has ten replicas spread across five machines, scaling up and down based on load. How does a request to that service's name actually get routed to a healthy replica, and how is this different from what Compose's DNS does?

A strong answer covers: Explains that discovery resolves a stable name to one of several currently-healthy, changing backend IPs, not a single fixed IP; Names a real mechanism (Swarm's routing mesh, or Kubernetes Service objects with kube-proxy or equivalent) rather than describing it only in the abstract; Contrasts this with Compose's embedded DNS, which resolves a name to one container's IP because there's typically only one; Connects load balancing to discovery as the same mechanism, not a bolted-on separate feature.

Compose resolving a service name to a container's IP feels like the whole story until a service has ten replicas instead of one — then 'resolve the name' quietly becomes 'resolve the name to whichever of ten, currently-changing IPs should handle this request.'

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

In Compose, a service name resolves to one container's IP because there's usually one container per service. Why doesn't that same simple mapping work once an orchestrator runs multiple replicas of a service?

There are multiple, constantly-changing healthy backends to choose from, not one fixed IP to map a name toDNS itself technically cannot return more than one IP address for a name under any circumstancesOrchestrators don't use DNS at all, so the comparison to Compose's DNS mechanism doesn't apply

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Service Discovery & DNS in Container Networks

What interviewers actually ask about this, and what a strong answer has to cover.

A service you're calling has ten replicas spread across five machines, scaling up and down based on load. How does a request to that service's name actually get routed to a healthy replica, and how is this different from what Compose's DNS does?

A strong answer covers

Explains that discovery resolves a stable name to one of several currently-healthy, changing backend IPs, not a single fixed IP
Names a real mechanism (Swarm's routing mesh, or Kubernetes Service objects with kube-proxy or equivalent) rather than describing it only in the abstract
Contrasts this with Compose's embedded DNS, which resolves a name to one container's IP because there's typically only one
Connects load balancing to discovery as the same mechanism, not a bolted-on separate feature

Likely follow-ups

What happens if a replica fails its health check but hasn't been removed from the discovery pool yet — what's the actual failure window there?
Would you ever hardcode a replica's IP address in application config instead of using the service name? Why or why not?

Practice these with the AI interviewer →

The plain-language idea

The Compose networking lesson earlier in this track covered the basic mechanism: on a user-defined bridge network, Docker runs an embedded DNS server, and a service name resolves directly to that one container's IP. This works cleanly because Compose almost always means one container per service — the name-to-IP mapping is simple because there's only ever one IP to map to.

Service discovery is what that same idea becomes once "one container" stops being true. An orchestrator (Swarm, Kubernetes, and similar) runs replicas — several interchangeable containers behind one logical service name — and replicas come and go constantly: scaled up, scaled down, replaced after a health check failure, rescheduled onto a different machine. Resolving a service name now has to answer a harder question: not "what's the IP," but "which of the currently healthy replicas should this particular request go to, right now." That's service discovery — DNS-by-name plus a live, constantly-updated membership list and a way to pick one, distributing load in the process.

See it in a real thing: one name, many changing backends

One name, three changing backends behind "api"Step 1 of 4

Three replicas of "api" are healthy — the name could resolve to any one of them.

Two real mechanisms implement this, and interviews tend to probe whether you know they're different tools solving the same problem:

Docker Swarm's routing mesh — every node in the swarm listens on the service's published port and routes incoming traffic to a healthy replica anywhere in the cluster, using an internal load-balancing layer, so a request can land on a node that isn't even running the container it ends up served by.
Kubernetes Service objects — a stable virtual IP and DNS name (api.namespace.svc.cluster.local, informally just api) backed by kube-proxy (or an equivalent), which continuously watches which pods currently match the Service's label selector and updates the routing accordingly as pods are created, destroyed, or fail health checks.

Both do the same conceptual job Compose's embedded DNS does at a single-host scale — resolve a stable name to a currently-correct backend — but neither is "Compose's DNS, but bigger." They're built around a continuously changing membership list, which is a genuinely different problem than resolving a name to one container that doesn't move.

What people usually miss

Watch out

A replica's IP is not a stable identifier — its name is. Code, config, and other services should never hardcode a replica's IP; the entire point of service discovery is that the IP behind a name is expected to change, sometimes within seconds.
Load balancing is a side effect of discovery, not a separate feature bolted on. Because the discovery layer already has to pick one healthy backend from several for every resolution, distributing those picks across replicas comes essentially for free — it's the same mechanism, not an add-on.
A newly-started replica isn't in the discovery pool until it's marked healthy. This is the same readiness distinction the rolling-updates lesson in this track raised — a container that's running but hasn't passed its health check yet shouldn't (and in a correctly configured system, won't) receive discovered traffic.
Compose's embedded DNS and an orchestrator's service discovery solve the same category of problem at different scales, not the same problem twice. Understanding one gives you the vocabulary for the other, but neither is a drop-in substitute — a Compose file has no concept of "route to whichever of these five replicas is healthy" at all.

Why this matters in interviews

"How does a service find and talk to another service when there might be ten replicas of it, spread across different machines, changing over time?" is a step up from the Compose-level "how does DNS resolve a service name" question, and answering it well means naming the actual mechanism — a continuously-updated membership list feeding load-balanced resolution — rather than describing single-container DNS at a larger scale.