Service Discovery

In a dynamic cloud environment, Pods are started and stopped constantly. Hardcoding IP addresses is impossible. Service Discovery is the "Phone Book" of your cluster. When Service A wants to talk to Service B, it asks the discovery tool: "Where is Service B right now?"

1. Server-Side Discovery (Kubernetes)

K8s has discovery built-in. When you create a Service called catalog-api, K8s creates a DNS entry. Your code can simply call http://catalog-api, and K8s intelligently routes the traffic to a healthy Pod.

2. Service Mesh (Consul / Istio)

For advanced scenarios, tools like **Consul** provides a global registry. It also handles **Health Monitoring**. If a service instance becomes slow or unhealthy, Consul automatically removes it from the "Phone Book" so no one tries to call it.

4. Interview Mastery

Q: "What is the difference between Client-Side and Server-Side service discovery?"

Architect Answer: "In **Client-Side** (e.g., Netflix Eureka), the client service itself is responsible for looking up the address and deciding which instance to call. In **Server-Side** (e.g., Kubernetes), the client just calls a static Load Balancer/Service URL, and the infrastructure handles the lookup and routing. Server-Side is much cleaner because your .NET code doesn't need to contain complex discovery logic; it just makes a standard HTTP call."