Service Discovery Pattern

It enables microservices to dynamically find and communicate with each other using a service registry. Services register themselves and can look up other services without manual configuration. Since service instances in a cloud environment are dynamic (they scale up/down and change IPs), a centralized registry is used to track their locations.

• It is essential in cloud environments where service instances frequently start or stop.
• Ensures automatic scaling, resilience and smooth inter-service communication.

Key components

• Service Provider: The microservice instance that needs to be “found.”
• Service Registry: A database containing the locations (IP and Port) of all available service instances (e.g., Netflix Eureka, Consul, Etcd).
• Service Consumer: The microservice that needs to call another service.

Discovery Types

• Client-Side Discovery
  • The client is responsible for looking up the service location from the registry and implementing load-balancing logic.
  • The client queries the Registry → receives a list of IPs → selects one (Round Robin/Random) → makes the call.
  • Example: Spring Cloud Netflix Eureka
• Server-Side Discovery
  • The client makes a request to a dedicated Load Balancer/Proxy, which handles the registry lookup and routing.
  • The client calls the Load Balancer → the Load Balancer queries the Registry → the Load Balancer routes the request.
  • Example: AWS ELB, Kubernetes Services (Kube-proxy)

The Registration Process

• Self-Registration: The service instance registers itself with the registry upon startup and sends periodic “heartbeats” to prove it is still healthy. If heartbeats stop, the registry removes the instance.
• Third-Party Registration: A separate “registrar” tool monitors the environment (e.g., Kubernetes) and automatically registers/deregisters instances as they are created or destroyed.

Client side vs server side discovery