Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Learn Client-Side vs Server-Side Discovery | Introduction to Service Discovery
Practice
Projects
Quizzes & Challenges
Quizzes
Challenges
/
Service Discovery with Spring

bookClient-Side vs Server-Side Discovery

Understanding Client-Side vs Server-Side Discovery

Service discovery is how applications find and communicate with each other in a distributed system. There are two main approaches: client-side discovery and server-side discovery. Each approach has unique benefits and trade-offs.

Client-Side Discovery

With client-side discovery, the client is responsible for determining the location of service instances. Here’s how it works:

  • The client queries a service registry to get a list of available service instances;
  • The client chooses an instance, often using a load-balancing algorithm;
  • The client sends the request directly to the chosen service instance.

Example:

Suppose you have a user-service and an order-service. The order-service wants to call the user-service. With client-side discovery, order-service asks the service registry (such as Eureka) for all available user-service instances. It picks one (for example, using round-robin load balancing) and sends the request directly.

Spring Implementation:

In Spring, you typically use Spring Cloud Netflix Eureka for the service registry and Spring Cloud LoadBalancer or Ribbon for client-side load balancing. Each service registers itself with Eureka, and clients use the @LoadBalanced annotation to inject a load-balanced RestTemplate or WebClient.

Pros:

  • Gives clients full control over load balancing and routing;
  • Reduces network hops, since clients talk directly to services;
  • Easy to implement in Spring with built-in support.

Cons:

  • Clients must know about the service registry and implement discovery logic;
  • Changes in service locations require all clients to be updated;
  • More complex client configuration.

Server-Side Discovery

With server-side discovery, the client sends requests to a load balancer or gateway, which then finds a service instance. Here’s how it works:

  • The client sends a request to a fixed endpoint (the load balancer or API gateway);
  • The load balancer queries the service registry to find available service instances;
  • The load balancer forwards the request to a suitable service instance.

Example:

The order-service wants to call the user-service. Instead of contacting user-service directly, it sends the request to an API gateway (such as Spring Cloud Gateway). The gateway looks up available user-service instances in the registry and forwards the request to one of them.

Choosing the Right Approach

Choose client-side discovery when you want lightweight infrastructure and clients can handle discovery logic. Use server-side discovery when you want to centralize routing, security, or monitoring, or when clients should remain simple.

Spring makes it easy to implement both approaches, so you can select the one that best fits your architecture and operational needs.

question mark

Which statement best describes client-side discovery in a service discovery system?

Select the correct answer

Everything was clear?

How can we improve it?

Thanks for your feedback!

SectionΒ 1. ChapterΒ 3

Ask AI

expand

Ask AI

ChatGPT

Ask anything or try one of the suggested questions to begin our chat

Suggested prompts:

Can you explain the main differences between client-side and server-side discovery in simpler terms?

What are some real-world scenarios where one approach is preferred over the other?

How does Spring Cloud Gateway fit into server-side discovery?

bookClient-Side vs Server-Side Discovery

Swipe to show menu

Understanding Client-Side vs Server-Side Discovery

Service discovery is how applications find and communicate with each other in a distributed system. There are two main approaches: client-side discovery and server-side discovery. Each approach has unique benefits and trade-offs.

Client-Side Discovery

With client-side discovery, the client is responsible for determining the location of service instances. Here’s how it works:

  • The client queries a service registry to get a list of available service instances;
  • The client chooses an instance, often using a load-balancing algorithm;
  • The client sends the request directly to the chosen service instance.

Example:

Suppose you have a user-service and an order-service. The order-service wants to call the user-service. With client-side discovery, order-service asks the service registry (such as Eureka) for all available user-service instances. It picks one (for example, using round-robin load balancing) and sends the request directly.

Spring Implementation:

In Spring, you typically use Spring Cloud Netflix Eureka for the service registry and Spring Cloud LoadBalancer or Ribbon for client-side load balancing. Each service registers itself with Eureka, and clients use the @LoadBalanced annotation to inject a load-balanced RestTemplate or WebClient.

Pros:

  • Gives clients full control over load balancing and routing;
  • Reduces network hops, since clients talk directly to services;
  • Easy to implement in Spring with built-in support.

Cons:

  • Clients must know about the service registry and implement discovery logic;
  • Changes in service locations require all clients to be updated;
  • More complex client configuration.

Server-Side Discovery

With server-side discovery, the client sends requests to a load balancer or gateway, which then finds a service instance. Here’s how it works:

  • The client sends a request to a fixed endpoint (the load balancer or API gateway);
  • The load balancer queries the service registry to find available service instances;
  • The load balancer forwards the request to a suitable service instance.

Example:

The order-service wants to call the user-service. Instead of contacting user-service directly, it sends the request to an API gateway (such as Spring Cloud Gateway). The gateway looks up available user-service instances in the registry and forwards the request to one of them.

Choosing the Right Approach

Choose client-side discovery when you want lightweight infrastructure and clients can handle discovery logic. Use server-side discovery when you want to centralize routing, security, or monitoring, or when clients should remain simple.

Spring makes it easy to implement both approaches, so you can select the one that best fits your architecture and operational needs.

question mark

Which statement best describes client-side discovery in a service discovery system?

Select the correct answer

Everything was clear?

How can we improve it?

Thanks for your feedback!

SectionΒ 1. ChapterΒ 3
some-alt