Why Service Discovery?

In modern microservices, you might have 100s of services running on 1000s of dynamically-allocated containers. How does service A find service B?

Old way (static):

billing.api.example.com -> 10.0.1.45

DNS resolves to ONE IP. Update DNS; wait for TTL to expire. Slow, lossy, manual.

New way (dynamic):

• Containers come and go (autoscaling, deploys, crashes)
• Multiple instances per service (load balancing)
• IPs change frequently
• Health varies

Service discovery is the abstraction:

client: "give me an instance of `billing-service`"
discovery: returns 10.0.1.45 (or 10.0.7.22 or 10.0.3.18 — pick one)

Two main flavors:

Client-side: client queries discovery, then connects directly. Examples: Eureka (Netflix), Consul DNS.

Server-side (proxy): client connects to load balancer; LB knows the backends. Examples: Kubernetes services (kube-proxy), Envoy + service mesh.

Modern apps use a mix. Kubernetes provides DNS-based server-side discovery; Consul + service meshes (Istio, Linkerd) provide both modes.