Service Discovery — design·lab

✗ Problem

Instances move — hard-coded addresses break

Autoscaling adds instances, crashes remove them, deploys replace them. "The order service" isn't one fixed IP:port — it's a moving target.

// works today, breaks tomorrow:
const orderSvc = "http://10.0.4.12:8080";
fetch(orderSvc + "/orders");
// ↑ that instance autoscaled down 5 min ago —
// every caller with this IP baked in now fails.

Hard-coded IPs assume a static world. In elastic, ephemeral infrastructure, every instance's address is temporary.

✓ How it works

A registry tracks healthy instances

Services register on startup and send heartbeats. The registry drops anything that stops beating. Two ways callers use it:

// client-side (Eureka + Ribbon)
instances = registry.lookup("order-svc");
target = loadBalance(instances); // caller picks
call(target);

// server-side (k8s Service, AWS ELB)
call("order-svc");  // LB looks up + picks

📖 Registry

register + heartbeat

↕

⚙️ Order #1

⚙️ Order #2

⚙️ Order #3

Client-side: the caller queries the registry and load-balances itself (extra client logic, no extra hop). Server-side: a load balancer / router queries the registry and forwards (simple clients, one central hop).

✓ See it live

Pick a discovery style — watch the messages

Same goal, different party does the lookup + load-balancing.

✓ Takeaway

Look up, don't hard-code

A registry gives dynamic location — only health-checked instances are returned.
Client-side: smart clients, no extra network hop (Eureka + Ribbon, Consul + client lib).
Server-side: simple clients, a central load balancer does the work (Kubernetes Service, AWS ELB/ALB).
DNS-based discovery (e.g. Kubernetes DNS, Consul DNS) is a common server-side flavor — clients just resolve a name.

🎯 Relates: once you have candidate instances, spreading load across them is consistent hashing / load balancing territory; a registry that also tracks health pairs naturally with a circuit breaker for failing instances.

Back to all topics →