Stop 20 · System DesignTopics · 9/15

Service Discovery

Part of the Backend Developer Roadmap

In short

In the cloud, servers come and go every hour with new IP addresses. Hardcoding 10.0.3.17 is a ticking bomb. Service discovery lets services find each other by name instead.

The mechanism by which services in a distributed system find each other's current network location — essential once services are dynamically scaled up/down and don't have fixed addresses.

The purple blob at a mall information desk points a shopper down the corridor.

Think of it like this

The mall information desk

Shops in a big mall move, close and open new outlets. Instead of printing addresses on every flyer, you ask the information desk 'where's the shoe shop?' and they check today's list. Service discovery is that desk: services register where they are, and others ask by name.

Watch it happen

Finding payments by name

Orders svc
Registry
Payments #1
Payments #2

register 10.0.3.17

1/6Payments instance 1 starts and registers itself under the name 'payments'.

The big ideas

What you need to know

A registry of who's alive

Instances register on start and send heartbeats. Missing heartbeats remove them from the list.

DNS-based discovery

In Kubernetes, a Service gets a stable DNS name like payments.default.svc that always points at ready pods.

Client-side vs server-side

The caller can pick an instance itself, or call a load balancer that does the lookup for it.

Health matters

Discovery only helps if dead instances disappear quickly. Pair it with health checks.

See it in code

Walk through the code

yaml
1apiVersion: v12kind: Service3metadata:4  name: payments5spec:6  selector:7    app: payments        # every pod with this label8  ports:9    - port: 8010      targetPort: 400011---12# In the orders service, just use the name:13# fetch("http://payments/charge")14# full form: http://payments.default.svc.cluster.local/charge

1/4The stable name other services will use.

Kubernetes keeps this name pointing at ready pods as they start, die and move. Docker Compose gives you a simpler version: service names resolve on the same network.

Save yourself the pain

Common mistakes

Oops

Hardcoding instance IPs in config files.

Do this instead

The first restart or autoscale breaks it. Use names that resolve through DNS or a registry.

Oops

Caching discovered addresses forever in the caller.

Do this instead

Dead instances keep getting calls. Respect DNS TTLs or refresh from the registry regularly.

Your mission

Discovery with Docker Compose

~30 min

Quick check

Why should services call payments by name instead of 10.0.3.17?

Go deeper

  1. 1Read how a service registry (e.g. Consul, or Kubernetes' built-in DNS) solves this problem.
  2. 2Understand why hardcoding IP addresses breaks down in any dynamically scaled system.
  3. 3Learn client-side vs server-side service discovery patterns.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge