Service Discovery
IntermediateService discovery enables services to find each other dynamically in a microservices environment where instances scale up/down and IPs change frequently. It replaces hardcoded addresses with a registry-based lookup.
Overview
In a microservices architecture, services are deployed across many hosts with dynamic IPs (especially in containers/Kubernetes). Hardcoding service addresses in configuration does not scale. Service discovery provides a registry where services register themselves and discover others. Client-side discovery means the client queries the registry and picks an instance (e.g. Netflix Eureka + Ribbon). Server-side discovery means a load balancer or DNS queries the registry on behalf of the client (e.g. Kubernetes Services, AWS ALB). In Kubernetes, every Service gets a stable DNS name (e.g. order-service.default.svc.cluster.local) backed by kube-proxy — no external registry needed. For non-Kubernetes environments, HashiCorp Consul, Netflix Eureka, or etcd provide service registries with health checking and DNS/HTTP interfaces.
Client-Side vs Server-Side Discovery
In client-side discovery, the client queries the service registry directly and performs load balancing. In server-side discovery, a load balancer or DNS handles the lookup transparently.
// Client-side discovery (Eureka + Spring Cloud)
// 1. Service registers itself with Eureka
// 2. Client queries Eureka for "ORDER-SERVICE"
// 3. Client gets list of IPs: [10.0.1.5:8080, 10.0.1.6:8080]
// 4. Client picks one (round-robin, random, etc.)
// Server-side discovery (Kubernetes)
// 1. Pod registers via Kubernetes API (automatic)
// 2. Client calls: http://order-service:8080/api/orders
// 3. kube-proxy resolves DNS → one of the pod IPs
// 4. Transparent to the client
// Kubernetes Service (server-side discovery)
apiVersion: v1
kind: Service
metadata:
name: order-service
spec:
selector:
app: order-service # matches pods with this label
ports:
- port: 8080
targetPort: 8080
type: ClusterIP # internal DNS: order-service.default.svc.cluster.localEureka & Consul
Eureka (Netflix OSS) and Consul (HashiCorp) are popular service registries for non-Kubernetes environments. They provide registration, discovery, and health checking.
// Spring Boot + Eureka registration
// application.yml
eureka:
client:
serviceUrl:
defaultZone: http://eureka-server:8761/eureka/
instance:
preferIpAddress: true
leaseRenewalIntervalInSeconds: 10
// Using discovered services with Feign client
@FeignClient(name = "ORDER-SERVICE") // resolves via Eureka
public interface OrderClient {
@GetMapping("/api/v1/orders/{id}")
OrderDTO getOrder(@PathVariable String id);
}
// Consul — service registration via agent
{
"service": {
"name": "order-service",
"port": 8080,
"check": {
"http": "http://localhost:8080/health",
"interval": "10s",
"timeout": "5s"
}
}
}
// DNS query: dig order-service.service.consulKey Points to Remember
- 1Service discovery replaces hardcoded addresses with dynamic registry-based lookup.
- 2Client-side discovery: client queries registry and load-balances (Eureka + Ribbon/Feign).
- 3Server-side discovery: load balancer or DNS resolves service names transparently (Kubernetes Services).
- 4Kubernetes provides built-in service discovery via DNS — no external registry needed.
- 5Health checks ensure only healthy instances are discoverable.
Interview Questions
Sign in to ask AriaWhat is service discovery and why is it needed?
Compare client-side and server-side service discovery.
How does Kubernetes handle service discovery?
What happens when a service instance crashes — how does discovery handle it?
Design a service discovery mechanism for a multi-region microservices deployment.
Ask Aria about Service Discovery
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.