Service Discovery: The Internal DNS of Microservices

Service Discovery: The Internal DNS of Microservices

As we continued our journey through distributed systems, we followed a request from the user’s browser through DNS, CDN, Load Balancers, Reverse Proxies, NGINX, and API Gateways. Each layer solved a specific problem. DNS helped users find applications, CDNs reduced latency by serving content closer to users, Load Balancers distributed traffic across healthy servers, Reverse Proxies handled SSL termination and routing, and API Gateways centralized authentication, authorization, and API management. At this point, the request reaches the Gateway and needs to be forwarded to the correct microservice. This raises an important question: How does the Gateway know where a service is actually running? The answer is Service Discovery. The Problem with Microservices In a monolithic application, everything runs inside a single process, so components communicate directly through function calls. There is no need to discover anything because all parts of the application already know where everything is. However, once an application is broken into multiple services such as Authentication, User, Hackathon, Leaderboard, Payment, and Notification Services, communication becomes much more complicated. Every service now needs to know how to reach other services. A beginner’s solution might be to use hardcoded IP addresses. For example, the API Gateway could be configured to send all Hackathon requests to 10.0.0.15. While this works initially, it quickly breaks down in modern cloud environments. Containers restart, servers are replaced, Pods move to different nodes, and auto-scaling creates new instances. The service that was previously running on 10.0.0.15 may suddenly be running on 10.0.0.42. Any component still trying to contact the old address will fail. This constant movement is what created the need for Service Discovery. Service Discovery: DNS for Microservices The easiest way to understand Service Discovery is by comparing it to DNS. When you type google.com into a browser, you do not know Google’s server IP addresses. DNS translates the human-friendly domain name into the correct IP address behind the scenes. Service Discovery applies exactly the same idea inside your infrastructure. Instead of services communicating with raw IP addresses, they communicate using logical names such as auth-service, payment-service, or hackathon-service. Whenever a service needs to contact another service, the Service Discovery system translates that logical name into the current location of a healthy instance. This is why Service Discovery is often described as Internal DNS for Microservices. The Service Registry To make Service Discovery possible, distributed systems introduced a component known as a Service Registry. The Service Registry acts as a central directory of all available services. Whenever a service starts, it registers itself with the registry along with information such as its IP address, port number, and health status. Later, when another service needs to communicate with it, the registry provides the location of a healthy instance. Rather than remembering server addresses, services simply ask the registry where another service currently lives. The registry responds with the latest available location, allowing communication to continue even if infrastructure changes behind the scenes. This completely removes the dependency on hardcoded IP addresses. A Simple Real-World Analogy Imagine working in a large corporate office. Suppose you need to find the Human Resources department. You probably do not memorize the floor number, room number, and desk location of every employee. Instead, you ask the receptionist where HR is located. The receptionist checks the directory and tells you where to go. If HR moves to another floor next week, the receptionist updates the directory while employees continue asking for "HR" rather than memorizing locations. A Service Registry plays exactly the same role in a distributed system. It acts as the receptionist that always knows where services are currently located. How Service Discovery Works The lifecycle of Service Discovery is relatively simple. When a service starts, it registers itself with the registry. The registry then continuously monitors the service using health checks or heartbeat messages. Whenever another service needs to communicate with it, the registry provides the address of a healthy instance. If the service crashes, the registry removes it from its records so that future requests are not sent to a failed instance. This process allows infrastructure to change constantly without affecting the applications that depend on it. Services can restart, scale up, scale down, or move between servers while communication continues seamlessly. Client-Side Service Discovery One of the earliest approaches to Service Discovery was Client-Side Discovery. In this model, the client itself is responsible for querying the registry. The client asks the registry for the available instances of a service, chooses one, and then sends the request directly. This approach gives applications more control and was popularized by systems such as Netflix Eureka. However, it also increases complexity because every client must contain logic for service discovery and load balancing. Server-Side Service Discovery Modern systems typically use Server-Side Discovery. In this approach, the client never communicates with the registry directly. Instead, requests are sent to infrastructure components such as Load Balancers, API Gateways, or Kubernetes Services. These components communicate with the registry and determine which service instance should handle the request. This keeps application code simple because developers no longer need to worry about discovering services. The infrastructure handles the complexity automatically. Kubernetes and Service Discovery Today, Kubernetes provides one of the most popular implementations of Service Discovery. Suppose an Authentication Service has three running Pods. Each Pod has a different IP address, and those IP addresses may change whenever Pods are recreated. Applications never communicate with those Pod addresses directly. Instead, they simply send requests to a stable name such as auth-service. Kubernetes DNS resolves that name and Kubernetes Services route traffic to healthy Pods. If a Pod crashes or a new one is created, Kubernetes updates its routing information automatically. Applications continue working without any knowledge of the infrastructure changes happening underneath them. This automation is one of the reasons Kubernetes became the standard platform for running microservices at scale. Why Service Discovery Matters Without Service Discovery, every infrastructure change would require configuration updates across multiple services. Scaling would become difficult, container restarts would frequently break communication, and cloud-native architectures would be extremely difficult to manage. With Service Discovery, services can move freely, restart safely, scale automatically, and recover from failures without breaking communication. Developers can think in terms of service names rather than machine addresses, allowing applications to remain independent from the underlying infrastructure. The Bigger Picture At this point, our request journey looks like this: User → DNS → CDN → Load Balancer → NGINX / Reverse Proxy → API Gateway → Service Discovery → Microservice Each layer answers a different question. DNS answers where the application lives. CDN answers whether content can be served closer to the user. Load Balancers determine which server should receive the request. NGINX handles SSL termination, compression, caching, and routing. API Gateways decide which service should handle the request and enforce policies such as authentication and rate limiting. Finally, Service Discovery answers the last infrastructure question: Where is the target service currently running? Conclusion Service Discovery may appear to be a small infrastructure component, but it is one of the foundational technologies that make modern microservices possible. It eliminates the need for hardcoded IP addresses, enables dynamic scaling, supports automatic failover, and allows services to move freely without disrupting communication. Just as DNS made the internet usable by replacing IP addresses with domain names, Service Discovery makes distributed systems manageable by replacing machine addresses with service names. With Service Discovery in place, we have now completed the entire request journey from a user’s browser to the correct service instance inside a distributed system. The next stage of our journey is not about finding services anymore—it is about surviving failures between them through concepts such as timeouts, retries, circuit breakers, bulkheads, and resilience patterns.