Mastering Service Discovery and Communication in Microservices

Service Registry

A service registry is a persistent store listing all available microservices and their access paths. Microservices interact with the registry for registration, health‑check signals, service discovery, and deregistration.

Third‑Party Registration vs Self‑Registration

Registration can be performed by a third‑party component that checks service health and forwards information to the registry, handling deregistration as well. This separates registration logic from business logic but requires an extra component and a health endpoint for polling. Self‑registration embeds registration and health‑check logic within the service itself, often using provided libraries to reduce code complexity.

Common Java‑based registry solutions include Consul, Eureka, and Amalgam8, all open‑source and supporting Java integration.

Availability vs Consistency

Registries offer either partition tolerance with consistency (e.g., Consul, Zookeeper) or availability (e.g., Eureka). Choose based on whether you need strict data consistency or fast responses.

Service Calls

When one service needs to communicate with another, it uses information from the registry to locate target instances.

Server‑Side Calls

Calls are routed through a service proxy that queries the registry, forwards the request, and returns the response. This centralizes load‑balancing but adds extra network hops.

Figure 1. Server‑Side Call via Service Proxy

Advantages: simple request, easier testing, and separation of load‑balancing logic. Drawback: increased network hops.

Figure 2. Network Hops with Service Proxy

Client‑Side Calls

The client queries the registry for service instances, caches locations, and calls the target directly, reducing hops.

Figure 3. Client‑Side Call Network Hops

Mechanisms: client libraries or sidecar processes. Sidecars run in a separate process alongside the service, providing language‑agnostic support.

Figure 4. Client Library vs Sidecar Architecture

Client Libraries

Libraries (e.g., Consul, Netflix Eureka) handle registration, health checks, and client‑side load balancing, allowing standardized usage across services.

Sidecar

A sidecar is a separate process deployed with the service, providing registration, health checks, and client‑side load balancing independent of language.

Examples include Netflix Prana, Kubernetes service‑mesh features, and Amalgam8.

API Gateway

API gateways perform service calls for internal and external clients, exposing a distinct API from the underlying services and handling routing and load balancing.

Microservice Communication

Communication can be synchronous (request/response) or asynchronous (event‑driven). Synchronous calls use REST/JSON APIs, while asynchronous messaging decouples services via events.

Synchronous Messaging (REST)

JAX‑RS 2.0 supports asynchronous programming via @Suspended AsyncResponse and @Asynchronous. Example:

@Stateless
@Path("/")
public class AccountEJBResource {
    @GET
    @Asynchronous
    @Produces(MediaType.APPLICATION_JSON)
    public void getAccounts(@Suspended final AsyncResponse ar) {
        Collection<Account> accounts = accountService.getAccounts();
        Response response = Response.ok(accounts).build();
        ar.resume(response);
    }
}

Reactive libraries like RxJava can also be used for asynchronous handling.

Asynchronous Messaging (Events)

Events decouple producers and consumers; services publish events and other services subscribe. Internal events can be implemented with CDI @Observes. Example:

public class PaymentEvent {
    public String paymentType;
    public long value;
    public String dateTime;
    public PaymentEvent() {}
}

public class PaymentEventHandler {
    public void credit(@Observes @Credit PaymentEvent event) {
        // handle credit
    }
}

Fault Tolerance

Microservices need resilience: adapt to API changes, handle unknown JSON properties, use timeouts, circuit breakers, bulkheads, and semaphores to isolate failures.

Timeouts and Circuit Breakers

Circuit breakers track failures; after a threshold they short‑circuit calls and optionally retry later.

Bulkheads

Bulkhead patterns isolate parts of the system, using fallback strategies, queues, or semaphores to prevent cascading failures.

Summary

The article covered methods for discovering services among many microservice instances, various communication patterns, and techniques for building resilient microservice architectures.