Microservices Architecture: Scenario-Based Questions

In microservices, services must find and talk to each other without hardcoding IPs or hostnames. Service discovery automates this process and enables scaling, resiliency, and decoupling.

🧭 What Is Service Discovery?

• Mechanism for dynamic location of services via name, tags, or roles.
• Handles scaling, failover, and topology changes transparently.

🏗️ Service Discovery Models

• Client-side discovery: Clients query registry (e.g., Eureka, Consul) and choose endpoint.
• Server-side discovery: A proxy/load balancer does discovery for clients (e.g., AWS ELB, Istio).

📦 Discovery Tools

• Consul: DNS and HTTP API-based registry with health checks.
• Eureka: Netflix OSS; popular with Spring Cloud ecosystem.
• Istio + Envoy: Transparent service mesh with traffic control and mTLS.
• Kubernetes: Native discovery via Services and DNS records.

🔧 Implementation in Kubernetes

• Each pod/service gets a stable DNS entry: my-service.namespace.svc.cluster.local.
• Service selectors and labels route traffic across ephemeral pods.
• Headless services + SRV records enable advanced routing.

✅ Best Practices

• Use health checks to avoid routing to unhealthy instances.
• Enable retries and circuit breakers for transient failures.
• Observe service-to-service latency and call graphs.

🚫 Common Pitfalls

• Hardcoding service IPs or relying on static DNS.
• No load balancing across replicas.
• Discovery logic buried deep in application code.

📌 Final Insight

Service discovery is the nervous system of microservices. A robust solution — whether mesh-based or registry-driven — ensures your services remain connected, resilient, and scalable.