Service Discovery

Overview

Service Discovery is how microservices find each other's network locations (IP addresses and ports) dynamically, without hardcoding them. Since cloud environments are ephemeral-instances spin up, crash, and scale down constantly-services need a real-time phonebook to know who to talk to.

🧠 Mental model: Think of it like DNS, but faster and specifically for internal microservices. When Service A wants to call Service B, it doesn't use a hardcoded IP. It asks the Service Registry, "Where does Service B live right now?"

Key Concepts

The Service Registry

The core component is the Service Registry (e.g., Consul, Eureka, Zookeeper, or etcd). It is a highly available database containing the network locations of all healthy service instances.

Registration: When a service instance starts, it registers itself with the registry.
Heartbeats: The instance periodically sends a heartbeat to say "I'm still alive." If the registry misses a heartbeat, it removes the instance.

Two Patterns of Discovery

Client-Side Discovery: The client (Service A) queries the Service Registry directly, gets a list of healthy Service B IPs, applies its own load balancing logic (like round-robin), and makes the request directly to one of the IPs. (Example: Netflix Ribbon + Eureka).
Server-Side Discovery: The client (Service A) sends the request to a Load Balancer or API Gateway. The Load Balancer queries the Service Registry and routes the request. The client doesn't even know the registry exists. (Example: Kubernetes Services, AWS ALB).

Trade-offs

Client-side discovery reduces network hops (the client talks directly to the target) and prevents a central load balancer from becoming a bottleneck. However, it requires you to implement discovery and load-balancing logic inside every client application (often across multiple programming languages). Server-side discovery simplifies the client code significantly but adds a network hop and requires managing a highly available load balancer.

Interview Tips

In modern system design, Server-Side Discovery is the default, primarily because Kubernetes handles this natively via its internal DNS and Service abstractions.
Mention that the Service Registry must be highly available (using a consensus algorithm like Raft) because if it goes down, services can't find each other.

Summary

Service discovery allows microservices to find each other dynamically without hardcoded IPs.
A Service Registry acts as a real-time phonebook of healthy instances.
Instances register on startup and maintain their status via heartbeats.
Client-side discovery puts the routing logic in the calling service.
Server-side discovery offloads routing to a load balancer or gateway (standard in Kubernetes).