Skip to main content Skip to search

Service Discovery

Service discovery is an essential part of modern microservices architectures. In this article we explain the basics of service discovery, including the service registry, client vs. server-based discovery, and self-registration vs. third-party registration.

In this page you will learn about 5 key strategies for implementing service delivery:

  • Service Discovery with Registry-Aware Clients
  • Client Side Service Discovery via Configuration Management
  • Server-Based Service Discovery via Load Balancing
  • Service-Based Service Discovery via DNS-SD
  • Service-Based Service Discovery via NS1’s Next-Gen DNS Platform

Service Discovery in a Microservices Environment:
5 Key Strategies

Soon, all complex applications will be architected as a group of independent microservices, not as a great monolith of code. A central challenge in microservices architectures is service discovery: how to ensure services can find and communicate with each other in a seamless manner, allowing for easy maintenance and further expansion of the application.

The Challenge of Service Discovery in a Microservices Architecture

In a microservices architecture, applications are built up of self-sufficient units, which can be deployed and updated independently, and communicate with each other via REST APIs.

One of the challenges in a microservices application is how services discover and connect to each other. With services scaling up and down their location is dynamic. Fixed IP addresses don't work so a more dynamic approach, usually involving a service registry is needed.

Microservices vs. Monolithic Applications

A monolithic application is a traditional software architecture, in which the application is a single unit, with interfaces to external systems like databases and web services. Service discovery is less complex because fewer components need to talk to each other - the application components are self contained.

However, monolithic applications are more difficult to maintain and add features and functions. A change in one component requires the entire application to be recompiled and tested. There are also scalability issues. An increase in demand for one function of the application (e.g. the user interface) means the entire application needs to be replicated and run on additional servers. A modular approach, in which each function is a separate microservice, is more flexible, maintainable and scalable.

How Service Discovery Works

Service discovery is a method for application components to locate each other. Service discovery in a microservices environment is a challenge because service instances are constantly being created and destroyed. The location and availability of those services needs constant updating.

Service Registry

A key component of service discovery in a microservices architecture is a service registry. The service registry is a database of available service instances. It contains the currently-available instances of each service and their connection details. Services query the service registry to retrieve the details for the required microservice, and then connect to it. The registry maintains a heartbeat mechanism to see if services are still up and if not, removes them from the registry.

Multi CDN Service Registry compressed

Microservice Registration Patterns

There are two primary microservice registration patterns:


A service instance registers itself with the service registry and makes itself available for discovery. On shutdown it unregisters itself.

Third-party registration

A 3rd party is responsible for identifying that a service has started, registering the service, and unregistering the service when it shuts down or crashes.

Multi CDN Microservice Registration compressed

Client Side vs. Server Side Service Discovery

There are two primary strategies for discovery of services via a service registry:

Client side discovery

The client contacts a service registry, receives details for available services, and contacts one of them using a load balancing algorithm.

Server side discovery

The client contacts a load balancer, making a request that indicates which type of service it needs. The load balancer consults the service registry, selects the optimal service (for example, the least loaded one) and routes the request to it. An example of a server-side discovery mechanism is AWS Elastic Load Balancing (ELB).


Five Strategies for Service Discovery in a Microservices Environment

  • Service Discovery with Registry-Aware Client
  • Client Side Service Discovery via Configuration Management
  • Server-Based Service Discovery via Load Balancing
  • Server Side Service Discovery with DNS-SD
  • Service Discovery with NS1’s Next-Gen DNS Platform

Strategy #1

Service Discovery with Registry-Aware Client

In this strategy the client is pre-built with the capability to contact the service registry and retrieve information about service instances. When the client requires a microservice, it finds a suitable service in the registry and connects to it directly. The assumption is that the registry tracks availability of services using a heartbeat mechanism.

Strategy #2

Client Side Service Discovery via Configuration Management

A most sophisticated form of client side service discovery is via configuration management tools, like Puppet or Chef. A configuration management tool can act as a service registry—services can use it to update their configuration when they start. However to make this strategy effective, services need to be registered in the configuration management tool very quickly and changes must be propagated immediately to prevent stale configuration.

Pros/cons: This removes the drawbacks of client side service discovery because there is central control over the load balancing. However still tightly coupled with client and requires full control over client environment.

Abstract night view of highway interchange wide with PA4 YV9 N compressed 2

DNS Propagation


In this article you’ll learn the causes of the propagation problem, “do it yourself” techniques to speed your propagation, and how to achieve near-instant DNS propagation with next-generation DNS technology.

Strategy #3

Server-Based Service Discovery via Load Balancing

Load balancing is commonly used as a service discovery mechanism; it provides health checks and can automatically register/unregister services when they fail. The load balancer works in tandem with the service registry.

DNS provides an easy way to connect microservices to the load balancer. You can configure a hostname for each microservice, register it on a DNS server and associate the hostname with the load balancer’s DNS name using a CNAME entry.


Clients are not tightly coupled to service registry

Can handle third-party clients

Reduced maintenance burden


Cost and complexity of setting up a load balancer

Load balancer is a single point of failure

Strategy #4

Server Side Service Discovery with DNS-SD

Service discovery can be achieved end-to-end using DNS infrastructure, removing the need to set up a load balancer or dedicated service registry.

The DNS Service Discovery (DNS-SD, RFC 6763) specification uses three DNS record types to define the location, status, type and capabilities for services:

PTR maps service types to named service instances

SRV provides location and port for service instances

TXT provides additional metadata about service instances

Here is a code example provided by Jan Algermissen, illustrating the process for basic usage of DNS-SD:

A service needs to access a service running the Atom Publishing Protocol. The domain setup for the microservices app is The service performs a DNS record lookup for Atom services at, using PTR records, as follows:

DNS-based load balancing is highly useful because it leverages existing DNS infrastructure, without having to set up new service discovery mechanisms, ensure they are reliable, and so on.


No tight coupling with clients

Relies on existing infrastructure, no need for load balancer

Highly available


Traditional DNS may have performance issues

Traditional DNS is slow to propagate—a service registry requires instant updates.

Traditional DNS servers are not aware of characteristics of hosts, so they have a limited ability to load balance, and might direct requests to a dead instance

Strategy #5

Service Discovery with NS1’s Next-Gen DNS Platform

NS1 is a DNS platform that meets the needs of modern service discovery. It guarantees fast DNS response and is able to propagate DNS SD changes in seconds across the enterprise, or around the globe.

NS1 solves the challenges of other service discovery approaches:

Does not require tight coupling with clients

Relies on existing DNS infrastructure, does not require load balancers

Highly available and fault tolerant

Fast and able to deal with rapid changes to services and serve them globally

NS1 Next-Gen DNS Features

In addition to seamlessly supporting service discovery, NS1 provides the world’s most advanced DNS traffic management system.

Start Now

Get a free trial of NS1 to see how to setup a fast, failsafe service discovery system using existing DNS infrastructure.