Understanding Service Discovery and Registration

Course: Advanced Java Training

Topic: Understanding Service Discovery and Registration

Course Link: Advanced Java Training Course

Demo Link: Register for a Course Demo

Website: JustAcademy

1. Introduction to Service Discovery and Registration

In modern distributed applications, especially microservices architectures, an application consists of multiple independent services that communicate with each other over a network. These services may run on different servers, containers, virtual machines, or cloud instances.

Because service instances can start, stop, scale, or move to different network addresses, maintaining fixed IP addresses and port numbers becomes difficult. Service discovery and service registration help applications locate available service instances dynamically.

Service registration allows a service instance to announce its availability and connection details to a registry. Service discovery allows another service or client to find an appropriate registered instance when it needs to communicate with that service.

For example, in an e-commerce application, the Order Service may need to communicate with the Payment Service. Instead of permanently storing the Payment Service's IP address, the Order Service can discover an available Payment Service instance through a service registry or discovery mechanism.

2. Learning Objectives

• Understand service registration and service discovery.
• Learn why dynamic service lookup is important in microservices.
• Understand service registries, health checks, and heartbeats.
• Compare client-side and server-side service discovery.
• Explore popular tools such as Netflix Eureka, Consul, and Kubernetes Services.
• Implement basic service registration and discovery using Spring Boot and Eureka.
• Understand failure handling, load balancing, security, and monitoring.
• Identify common service discovery problems and their solutions.

3. What Is Service Registration?

Service registration is the process by which a running service instance publishes information about itself to a service registry or makes itself available through a platform-managed discovery mechanism.

The registration information may include the service name, host or network address, port, health status, metadata, and instance identifier. The exact information depends on the discovery technology being used.

3.1 Example of Service Registration

Suppose a Payment Service starts on a server with the address 192.168.1.20 and port 8082. It registers its instance information under the logical service name PAYMENT-SERVICE.

Service Name: PAYMENT-SERVICE
Instance ID: payment-service-01
Host: 192.168.1.20
Port: 8082
Status: UP

Another application can use the logical service name to locate the Payment Service rather than depending directly on the instance's physical address.

3.2 Why Is Service Registration Required?

• It allows services to announce their availability dynamically.
• It reduces dependence on hard-coded IP addresses and ports.
• It supports applications with multiple instances of the same service.
• It helps discovery systems maintain a directory of service instances.
• It supports dynamic scaling and changing deployment environments.
• It can provide metadata that assists routing and service selection.

4. What Is Service Discovery?

Service discovery is the process of locating a service instance at runtime. A client or another service queries a registry, uses DNS, or relies on platform networking to find the appropriate destination.

For example, the Order Service wants to send a request to the Payment Service. The discovery mechanism finds an available instance and supplies a destination that the Order Service can call.

4.1 Example of Service Discovery

Order Service
      |
      | Request: Find PAYMENT-SERVICE
      v
Service Registry
      |
      | Returns available instance(s)
      v
Payment Service Instance
192.168.1.20:8082

The Order Service can now communicate with the selected Payment Service instance. In a load-balanced environment, the system may select one of several healthy instances.

4.2 Benefits of Service Discovery

• Dynamic lookup: Applications can find services without fixed instance addresses.
• Scalability: New service instances can be added as demand increases.
• Resilience: Unhealthy or unavailable instances can be excluded when health information is accurate and current.
• Load distribution: Requests can be distributed among multiple service instances.
• Deployment flexibility: Services can move between hosts or containers without requiring every caller to be manually updated.
• Reduced configuration overhead: Centralized discovery can simplify endpoint management.

5. What Is a Service Registry?

A service registry is a directory that stores or makes available information about service instances. Depending on the technology, it may be a dedicated registry server, a distributed key-value store, a DNS-based system, or functionality provided by a container orchestration platform.

5.1 Common Registry Information

5.2 Role of the Registry

The registry maintains information that helps consumers locate service instances. Depending on the implementation, it may accept registrations, track health information, remove expired instances, return discovery results, and replicate registry data for availability.

A registry does not necessarily proxy application requests. In many implementations, it simply provides discovery information, and the client then connects directly to the selected service instance.

6. How Service Registration and Discovery Work Together

Registration and discovery are complementary processes. Registration makes a service discoverable, while discovery uses the available registration information to locate it.

Step-by-Step Workflow

1. Service startup: A service instance starts in its runtime environment.
2. Registration: The instance registers its service name and connection information, or becomes available through the platform's service mechanism.
3. Health reporting: The instance or platform reports health information through heartbeats, health checks, leases, or another supported mechanism.
4. Discovery request: A consumer requests the available instances for a logical service name or resolves a service address through the platform.
5. Instance selection: The discovery or load-balancing mechanism selects an appropriate destination.
6. Communication: The consumer sends its request to the selected instance.
7. Health changes: If an instance becomes unavailable, the system updates or expires its registration according to its failure-detection rules.
8. Re-discovery: Subsequent requests can use an updated list of available instances.

6.1 Architecture Diagram

             +----------------------+
             | Service Registry     |
             | Eureka / Consul      |
             +----------------------+
                ^              |
                |              |
          Registration      Discovery
                |              |
       +----------------+      |
       | Payment Service|      |
       | Instance       |      |
       +----------------+      |
                               v
                       +----------------+
                       | Order Service  |
                       | Consumer       |
                       +----------------+
                               |
                               | HTTP Request
                               v
                       +----------------+
                       | Selected       |
                       | Payment Service|
                       +----------------+

This diagram illustrates the logical workflow. The actual communication path depends on whether discovery is client-side, server-side, DNS-based, or managed by an orchestration platform.

7. Types of Service Discovery

7.1 Client-Side Service Discovery

In client-side discovery, the client obtains a list of service instances from a registry or discovery API and selects an instance. The client may use a load-balancing component to distribute requests across available instances.

Workflow:

1. The client requests instances for a logical service name.
2. The registry returns the available instances.
3. The client-side load balancer selects a destination.
4. The client sends the request directly to that destination.

Advantages:

• Supports client-controlled instance selection and load balancing.
• Can reduce the need for a separate routing proxy.
• Allows the client to use discovery data for request routing decisions.

Disadvantages:

• Clients need a compatible discovery mechanism or library.
• Discovery caching and stale instance information must be handled.
• Different clients may require additional configuration and maintenance.

7.2 Server-Side Service Discovery

In server-side discovery, the client sends its request to a router, gateway, or load balancer. That component selects an available service instance and forwards the request.

Workflow:

1. The client sends a request to a stable service endpoint.
2. The router or load balancer identifies the destination service.
3. The routing component selects an available instance.
4. The request is forwarded to the selected instance.

Advantages:

• Clients do not need to implement instance-selection logic themselves.
• Routing policies can be managed centrally.
• Centralized infrastructure can provide consistent traffic controls.

Disadvantages:

• Routing infrastructure must be operated and secured.
• The router can become a bottleneck if it is not scaled properly.
• High availability and routing configuration require careful design.

7.3 Client-Side vs. Server-Side Discovery

8. Service Discovery Technologies

8.1 Netflix Eureka

Netflix Eureka is a service registry and discovery system commonly used in Spring Cloud applications. Services can register themselves with a Eureka Server, and discovery clients can obtain information about registered service instances.

Common components:

• Eureka Server: Provides the service registry.
• Eureka Client: Registers an application instance and obtains discovery information.
• Service ID: Identifies a logical service, such as PAYMENT-SERVICE.
• Instance Information: Contains the address and port used to contact a service instance.
• Heartbeats and Expiration: Help the registry maintain an approximate view of instance availability.

Eureka is useful in environments that use compatible Spring Cloud Netflix components. Its exact configuration and behavior depend on the selected Spring Boot and Spring Cloud versions.

8.2 Consul

Consul provides service discovery, health checking, and a key-value store, with additional networking capabilities available in supported configurations.

It can be used to register services, check service health, and discover service instances in distributed environments. Consul supports integration with applications that use different programming languages and platforms.

8.3 Kubernetes Service Discovery

Kubernetes provides service discovery through Services and DNS. A Kubernetes Service offers a stable logical endpoint for a set of selected Pods, while the platform manages the changing set of backend endpoints.

Applications commonly communicate using a service DNS name rather than maintaining individual Pod IP addresses. Kubernetes handles service routing according to the Service type and cluster networking configuration.

8.4 DNS-Based Service Discovery

DNS-based discovery allows a consumer to resolve a logical hostname into an IP address or set of addresses. DNS can simplify discovery for applications that do not need a dedicated registry client.

However, DNS caching, record updates, TTL values, and load-balancing behavior affect how quickly clients observe changes. DNS-based discovery does not automatically provide every registry feature, such as application-level metadata or health-aware selection in every configuration.

8.5 Comparison of Popular Technologies

9. Implementing Service Discovery with Spring Boot and Eureka

In this example, we will create three applications:

• Eureka Server: Runs the service registry.
• Payment Service: Registers itself with Eureka.
• Order Service: Discovers and calls the Payment Service.

Use mutually compatible Spring Boot and Spring Cloud release versions. The dependency names and configuration shown below are illustrative; consult the documentation for the versions selected for your project.

9.1 Step 1: Create the Eureka Server

Create a Spring Boot project named eureka-server. Add the Eureka Server dependency using Spring Initializr or the appropriate Spring Cloud dependency management setup.

For a Maven project, the relevant dependency is typically:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Use a compatible Spring Cloud BOM in the Maven configuration so that the Spring Cloud dependencies match the Spring Boot version.

9.2 Enable the Eureka Server

package com.example.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(
            EurekaServerApplication.class, args);
    }
}

Explanation: The @EnableEurekaServer annotation configures the application to provide a Eureka service registry.

9.3 Configure the Eureka Server

Add the following configuration to the Eureka Server's application.yml:

server:
  port: 8761

spring:
  application:
    name: eureka-server

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

These settings configure the application to run on port 8761 and avoid registering the standalone registry with itself. This is a simple development setup, not a complete production high-availability configuration.

9.4 Step 2: Create the Payment Service

Create another Spring Boot project named payment-service. Add the Spring Web dependency and the Eureka client dependency supported by the selected Spring Cloud release.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

In the Payment Service's application.yml, configure the application name and registry URL:

server:
  port: 8082

spring:
  application:
    name: PAYMENT-SERVICE

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

When the service starts with the appropriate Eureka client configuration, it can register its instance with the Eureka Server.

9.5 Create a Payment Controller

package com.example.paymentservice;

import org.springframework.web.bind.annotation.*;
import java.util.Map;

@RestController
@RequestMapping("/api/payments")
public class PaymentController {

    @GetMapping("/status")
    public Map<String, String> getPaymentStatus() {
        return Map.of(
            "service", "PAYMENT-SERVICE",
            "status", "Payment service is available"
        );
    }
}

This endpoint returns a simple status response. A real payment application would require proper authentication, authorization, payment-provider integration, validation, and error handling.

9.6 Step 3: Create the Order Service

Create a Spring Boot project named order-service. Add Spring Web, the Eureka client dependency, and Spring Cloud LoadBalancer if required by your chosen discovery and load-balancing setup.

Configure application.yml as follows:

server:
  port: 8081

spring:
  application:
    name: ORDER-SERVICE

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

9.7 Configure a Load-Balanced HTTP Client

The following example uses Spring's RestClient with a Spring Cloud LoadBalancer integration. Ensure the appropriate LoadBalancer dependency and configuration are present.

package com.example.orderservice;

import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestClient;

@Configuration
public class HttpClientConfig {

    @Bean
    @LoadBalanced
    RestClient.Builder restClientBuilder() {
        return RestClient.builder();
    }
}

The @LoadBalanced annotation allows the configured client to use a logical service name for load-balanced requests when the necessary Spring Cloud integrations are available.

9.8 Call the Payment Service by Its Service Name

package com.example.orderservice;

import org.springframework.web.bind.annotation.*;
import org.springframework.web.client.RestClient;

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final RestClient restClient;

    public OrderController(RestClient.Builder builder) {
        this.restClient = builder
            .baseUrl("http://PAYMENT-SERVICE")
            .build();
    }

    @GetMapping("/payment-status")
    public String getPaymentStatus() {
        return restClient.get()
            .uri("/api/payments/status")
            .retrieve()
            .body(String.class);
    }
}

Explanation: The Order Service uses PAYMENT-SERVICE instead of a hard-coded host and port. The configured Spring Cloud load-balancing integration resolves the logical service name to a registered instance.

Important: This code illustrates the discovery pattern. Depending on the Spring Boot and Spring Cloud versions, the available HTTP client integration and bean configuration may differ. Configure suitable connection and response timeouts and handle downstream errors in a production implementation.

9.9 Step 4: Run the Applications

1. Start the Eureka Server on port 8761.
2. Start the Payment Service on port 8082.
3. Start the Order Service on port 8081.
4. Open http://localhost:8761 in a browser to inspect the Eureka dashboard in a typical development setup.
5. Call http://localhost:8081/api/orders/payment-status.
6. Verify that the Order Service obtains a response through the discovered Payment Service.

The dashboard and registry state can take some time to reflect a new registration. Confirm that the services are running, the registry URL is correct, and the client dependencies and configuration are compatible if registration does not appear.

10. Registration Lifecycle

A service's registration changes throughout its lifecycle. Understanding this lifecycle is important for maintaining accurate discovery information.

10.1 Startup and Registration

When an instance starts, it initializes its application components and registers itself through the discovery mechanism. The registry or platform records the instance's address and other supported details.

10.2 Heartbeats and Leases

Some registries use periodic heartbeats or leases to determine whether an instance is still active. If expected heartbeats stop arriving, the registry may eventually consider the instance expired.

Failure detection is not instantaneous. Network interruptions, temporary overload, and delayed heartbeats can cause a healthy service to appear unavailable or a failed instance to remain visible temporarily.

10.3 Health Checks

Health checks help determine whether a service is able to handle requests. Depending on the platform, health checks may verify process status, application readiness, dependencies, or custom business conditions.

A running process is not necessarily ready to handle traffic. Readiness checks should distinguish a service that has started from one that is ready to serve requests.

10.4 Deregistration

When a service shuts down gracefully, it may deregister itself so that it is no longer selected for new requests. Platform-managed systems may instead update endpoint membership automatically as instances are removed.

Unexpected crashes may prevent graceful deregistration, which is why registries and platforms need expiration, health-check, or reconciliation mechanisms.

11. Load Balancing and Service Discovery

Service discovery identifies available service instances, while load balancing distributes requests among selected instances. These functions are closely related but are not the same.

For example, if three Payment Service instances are registered, a load balancer may distribute requests among them according to its routing algorithm and health information.

11.1 Common Load-Balancing Strategies

• Round Robin: Distributes requests across instances in sequence.
• Weighted Distribution: Sends different proportions of traffic to instances based on configured weights.
• Least Connections: Prefers an instance with fewer active connections when the implementation supports this strategy.
• Latency-Aware Selection: Uses response-time information to guide routing where supported.
• Zone-Aware Routing: Can prefer instances in the same availability zone to reduce latency or cross-zone traffic.

The actual algorithms available depend on the load balancer and its configuration. Discovery alone does not guarantee that traffic will be evenly distributed or that every selected instance is healthy.

12. Service Discovery in Kubernetes

Kubernetes offers built-in service discovery that is particularly useful for containerized Java microservices. A Kubernetes Service provides a stable endpoint for a set of Pods selected by labels, while Pods may be replaced or assigned different IP addresses over time.

12.1 Example Kubernetes Service

apiVersion: v1
kind: Service
metadata:
  name: payment-service
spec:
  selector:
    app: payment-service
  ports:
    - name: http
      port: 8082
      targetPort: 8082
  type: ClusterIP

This YAML defines a ClusterIP Service named payment-service that forwards traffic to matching Pods on port 8082. The matching Deployment or Pods must use the corresponding label and expose the expected application port.

12.2 Accessing a Service by DNS Name

Within the same Kubernetes namespace, another application can typically access the service using a hostname such as:

http://payment-service:8082

For a service in another namespace, a fully qualified service DNS name can be used, such as:

http://payment-service.payments.svc.cluster.local:8082

The exact cluster domain can vary by Kubernetes configuration. Kubernetes Service discovery is platform-managed and does not require an application to register each Pod manually with Eureka.

13. Common Service Discovery Challenges

13.1 Stale Service Information

A consumer may use an outdated instance list after a service stops or changes address.

Solutions:

• Use appropriate cache expiration and refresh behavior.
• Configure health checks or instance leases correctly.
• Handle connection failures and refresh discovery information when appropriate.
• Use suitable request timeouts and bounded retries.

13.2 Registry Unavailability

If a registry becomes unavailable, services may be unable to register new instances or refresh discovery information. Some clients can continue using cached data, but this depends on the technology and configuration.

Solutions:

• Design registry infrastructure for high availability when required.
• Monitor registry health and latency.
• Understand how clients behave when discovery requests fail.
• Test recovery scenarios before production deployment.

13.3 Incorrect Service Names

A consumer may request a service name that does not match the registered logical name. This can result in failed discovery or routing errors.

Solutions:

• Use consistent naming conventions.
• Keep service names in centralized configuration where appropriate.
• Verify registry entries and client configuration during troubleshooting.

13.4 Unhealthy Instances

An instance may remain registered even though it cannot successfully process requests. Health detection and instance-selection policies must be configured to reduce traffic to unhealthy destinations.

13.5 Network and DNS Problems

Firewall rules, DNS failures, incorrect ports, and container networking issues can prevent a consumer from reaching a discovered instance.

Solutions: Check name resolution, network connectivity, listening ports, security rules, service endpoints, and application logs.

14. Security Best Practices

• Protect registry and management endpoints from unauthorized access.
• Use secure communication channels where appropriate.
• Authenticate and authorize service-to-service requests.
• Restrict network access to trusted services and infrastructure.
• Protect configuration files and secrets.
• Avoid exposing internal service registries publicly without a justified and secured design.
• Validate service metadata and control which identities can register services.
• Monitor unexpected registrations, deregistrations, and health changes.
• Apply least-privilege permissions to registry APIs and infrastructure accounts.

15. Monitoring and Troubleshooting

Service discovery should be monitored as a critical part of distributed application infrastructure.

15.1 Useful Monitoring Metrics

• Number of registered instances per service.
• Registration and deregistration failures.
• Discovery request latency and error rate.
• Registry health and availability.
• Heartbeat delays or expired instances.
• Downstream request failures and response times.
• Load-balancer routing failures.

15.2 Troubleshooting Checklist

1. Confirm that the registry or discovery platform is running.
2. Verify the service name and registry endpoint.
3. Check that the application has the correct dependencies and configuration.
4. Inspect logs for registration, DNS, network, or connection errors.
5. Verify the service's listening port and network accessibility.
6. Check health and readiness status.
7. Confirm that the client uses a discovery-aware HTTP client or the correct platform endpoint.
8. Inspect load-balancer configuration and service instance selection.
9. Test failure recovery after an instance is stopped or restarted.

16. Practical Hands-On Exercise

Project: Create an Order and Payment microservices system using Spring Boot and Eureka.

Requirements

• Create a Eureka Server that acts as a registry.
• Create a Payment Service with a REST endpoint.
• Register the Payment Service using its logical application name.
• Create an Order Service that discovers the Payment Service.
• Use a load-balanced HTTP client to call the discovered service.
• Run the applications on separate ports.
• Test the system when the Payment Service is running and when it is stopped.
• Review registry information and application logs.

Expected Learning Outcomes

• Understand dynamic service registration.
• Call a service without hard-coding its instance address.
• Observe how the registry tracks service instances.
• Understand the effect of unavailable instances on consumers.
• Practice configuration, debugging, and resilience techniques.

17. Interview Questions and Answers

Q1. What is service discovery?

Answer: Service discovery is the process of locating available service instances dynamically through a registry, DNS, or a platform-managed networking mechanism.

Q2. What is service registration?

Answer: Service registration makes an instance discoverable by publishing or maintaining its identity and connection information through the relevant discovery system.

Q3. What is a service registry?

Answer: A service registry maintains information about service instances so consumers or routing components can locate them.

Q4. What is the difference between service registration and discovery?

Answer: Registration advertises a service instance, while discovery retrieves or resolves information needed to locate that instance.

Q5. What is Netflix Eureka?

Answer: Netflix Eureka is a registry and discovery technology used by compatible applications to register service instances and obtain information about other services.

Q6. What is the role of a Eureka Server?

Answer: The Eureka Server provides the registry where service instances register and from which discovery clients can retrieve instance information.

Q7. What is a Eureka Client?

Answer: A Eureka Client is an application component that can register its own instance and obtain discovery information from a Eureka Server.

Q8. What is client-side service discovery?

Answer: In client-side discovery, the consumer obtains instance information and selects the destination, often using a client-side load balancer.

Q9. What is server-side service discovery?

Answer: In server-side discovery, a gateway, router, or load balancer selects the service instance and forwards the request.

Q10. What is a heartbeat in service discovery?

Answer: A heartbeat is a periodic signal used by some systems to indicate that a service instance is still active. Missing heartbeats can eventually cause an instance to expire.

Q11. What happens if a registered service crashes?

Answer: The discovery system may continue to show the instance temporarily. Health checks, heartbeats, leases, or endpoint reconciliation eventually help remove or exclude it, depending on the platform.

Q12. How does Kubernetes provide service discovery?

Answer: Kubernetes Services provide stable logical endpoints for matching Pods, and cluster DNS allows applications to resolve service names.

Q13. Why should developers avoid hard-coded service IP addresses?

Answer: Instance addresses can change during restarts, scaling, and deployments. Logical names and discovery mechanisms reduce manual configuration and make applications more adaptable.

Q14. How is service discovery related to load balancing?

Answer: Discovery identifies available instances, while load balancing selects or distributes requests among them. The two functions can be integrated but are conceptually different.

Q15. Can microservices work without a dedicated service registry?

Answer: Yes. DNS, static configuration, platform-managed service endpoints, and orchestration systems can provide discovery without a separate registry server.

Q16. What is the purpose of health checks?

Answer: Health checks help determine whether an instance is ready or able to serve requests, allowing discovery and routing systems to make better decisions.

Q17. What is the difference between service discovery and an API gateway?

Answer: Service discovery locates service instances. An API gateway accepts client requests and can route them to services while providing additional cross-cutting capabilities.

Q18. How can service discovery be made more reliable?

Answer: Use appropriate health checks, resilient registry infrastructure, secure configuration, sensible caching, monitoring, request timeouts, and tested failure-recovery procedures.

18. Quick Revision Checklist

• Service registration publishes or maintains instance information.
• Service discovery helps consumers locate available services.
• A service registry stores or provides discovery information.
• Client-side discovery lets the client select a destination.
• Server-side discovery uses a router or load balancer for instance selection.
• Eureka is commonly used with Spring Cloud applications.
• Kubernetes uses Services and DNS for platform-managed discovery.
• Heartbeats, leases, and health checks help track instance availability.
• Load balancing and discovery are related but distinct concepts.
• Security, monitoring, timeout handling, and failure recovery are essential.

19. Conclusion

Service discovery and registration are fundamental concepts in microservices architecture. Registration makes a service instance available to the discovery system, while discovery enables other applications to locate appropriate instances dynamically.

Technologies such as Netflix Eureka, Consul, DNS, and Kubernetes Services provide different approaches to discovering services. The right choice depends on the application architecture, deployment environment, operational requirements, and technology stack.

For Java developers, learning service discovery with Spring Boot and Spring Cloud helps build distributed applications that can scale, adapt to changing environments, and communicate without relying entirely on fixed instance addresses.

20. Further Learning Resources

Explore the Advanced Java Training Course at JustAcademy to learn more about Java, Spring Boot, microservices, and enterprise application development.

To learn about available training options, visit the JustAcademy Course Demo Registration page.

Explore additional programming and professional training resources on the JustAcademy website.

End of Notes: Understanding Service Discovery and Registration