Service Discovery

Service addresses change in a dynamic system

In a small system, a dependency address can be written into configuration. With horizontal scaling, however, instances appear, restart, and disappear, and their network addresses may change. A hard-coded list quickly becomes unreliable.

Service Discovery solves the problem of finding available instances by a service's logical name. A consumer says “I need orders,” and the discovery mechanism helps obtain current connection endpoints.

orders -> [10.0.1.8:8080, 10.0.2.4:8080]

Registration and discovery are both needed

To find an instance, the system first needs to know which instances exist. In one approach, services register themselves in a dedicated registry; in another, the platform builds the list automatically from its own state.

The client or an intermediary infrastructure component then obtains the current endpoints and chooses one of the available instances for the call.

Client-side and server-side discovery

With client-side discovery, the calling service obtains the instance list and selects an address itself. With server-side discovery, the client calls a stable entry point, and an intermediary component chooses the concrete instance.

client-side: app -> registry -> service instance
server-side: app -> stable endpoint -> service instance

The first approach gives the client more control but adds discovery logic to applications. The second keeps the client simpler but moves responsibility to an infrastructure layer.

The list must reflect real availability

Registering an instance once is not enough. If it stops serving requests, information about it must be removed or stop being used. Discovery is therefore usually connected to health checks, heartbeat mechanisms, or orchestrator state.

Updates are not always instantaneous. A client may briefly receive a stale endpoint, which means network failures, timeouts, and retries still remain part of reliable communication.