Skip to content

Service Discovery

1. What is it? (2-3 lines)

Service Discovery is a mechanism that automatically tracks the dynamic network locations (IP addresses and ports) of microservice instances in a cloud/containerized cluster, allowing services to find and communicate with each other seamlessly.

2. Why does it exist?

In modern cloud environments (Kubernetes, AWS ECS, Autoscaling Groups), container instances constantly scale up, scale down, crash, or move across physical nodes, acquiring ephemeral IP addresses. Hardcoding IP addresses is impossible. Service Discovery automates dynamic IP tracking and routing.

3. Where is it used?

  • Server-Side Discovery: Kubernetes ClusterIP / Ingress, AWS ALB / Cloud Map.
  • Client-Side Discovery: Netflix Eureka, HashiCorp Consul, HashiCorp Serf.
  • Service Mesh: Istio, Linkerd (Envoy sidecars query discovery control plane).

4. How does it work? (simple flow)

  • Client-Side Discovery Pattern:
  • Registration: Microservice instance boots \(\to\) Registers its IP/Port with Service Registry (Consul/Eureka).
  • Heartbeat: Service sends periodic health checks to maintain active registry status.
  • Lookup: Calling Service queries Service Registry \(\to\) Obtains list of healthy instance IPs \(\to\) Executes local client-side load balancing (e.g. Round-Robin).
  • Server-Side Discovery Pattern (Kubernetes):
  • Service instance boots \(\to\) K8s API Server updates Service Endpoints object.
  • Client calls virtual Service IP (payment-service:8080) \(\to\) Kube-Proxy (via iptables/eBPF) intercepts packet and routes to a healthy pod IP transparently.

5. Advantages

  • Fully automates dynamic cloud instance routing during auto-scaling and deployments.
  • Integrated health checking removes dead or unhealthy instances from routing pools instantly.
  • Enables blue-green, canary, and zero-downtime rolling deployment strategies.

6. Limitations

  • Service Registry outage blocks inter-service communication across the entire cluster (Single Point of Failure if un-clustered).
  • Client-side discovery requires implementing SDKs for every programming language in a polyglot architecture.

7. Common interview questions (10)

  1. What is the fundamental difference between Client-Side Discovery and Server-Side Discovery?
  2. How does Kubernetes implement Server-Side Service Discovery using CoreDNS and Kube-Proxy?
  3. How does HashiCorp Consul maintain strong consistency in its Service Registry using Raft?
  4. How does Netflix Eureka achieve high availability via AP (Eventual Consistency) principles?
  5. How do Service Meshes (Istio/Envoy) offload Service Discovery away from application code?
  6. What is DNS Caching and why can TTL values cause stale routing during rapid auto-scaling?
  7. How does a Service Registry handle network partitions and stale instance deregistration?
  8. How do Health Checks integrate with Service Discovery registries?
  9. When should an enterprise choose Consul over Kubernetes native DNS discovery?
  10. How does Service Discovery support Canary deployments and Weighted Traffic Splitting?

8. Common misconceptions

  • Misconception: DNS is sufficient for high-velocity microservice discovery out-of-the-box. Fact: OS and JVM DNS caching frequently ignores short TTLs, routing traffic to dead pod IPs.
  • Misconception: Client-side discovery requires an external load balancer. Fact: Client-side discovery runs load balancing algorithms directly inside the calling application's memory space.

10. 30-second cheat sheet

  • Client-Side (Eureka/Consul): App queries Registry \(\to\) App load-balances locally. Needs SDKs.
  • Server-Side (K8s/ALB): App calls Virtual IP \(\to\) Router/Kube-Proxy routes to healthy instance. Transparent!
  • Core Component: Service Registry (Centralized database of active Service_Name \(\to\) IP:Port mappings).
  • DNS Caveat: Beware JVM DNS caching (networkaddress.cache.ttl) overriding dynamic service discovery updates.