How to Build a Scalable Service Registry for Microservices

How to call?

Method 1: The provider tells you the address directly.

Method 2: The provider stores the API address in a shared location.

Method 3: Use Nginx to forward a domain name to a specific instance.

In real production environments services run in clusters with many instances; static address methods become problematic when instances go down or new ones appear.

Why a registry?

A third‑party node can store service information, allowing consumers to retrieve it by knowing only the registry address.

We refer to the service provider as provider and the consumer as consumer .

Designing a Service Registry

Key problems to solve:

How services register

How consumers discover providers

How to ensure high availability of the registry

How consumers dynamically detect service up/down events

Service Registration

After a service registers, the registry stores the service list (e.g., in memory, a database, or a cache).

Consumers query the registry with a key to obtain the list of service addresses.

Service Consumption

Consumers retrieve the address list by key and use it to invoke providers.

High Availability

Deploy multiple registry nodes as a cluster; consumers need only know the cluster-url of the registry.

Dynamic Service Up/Down Detection

Consumers cache the service list locally. The registry performs heartbeat checks ( heartBeat) on providers; if a provider fails, its address is removed from the list.

When a new instance appears, the registry adds its address to the list.

Consumers must stay synchronized with the registry, which can be achieved via push or pull mechanisms.

Push: the registry actively pushes updated lists to consumers.

Pull: consumers periodically pull the list from the registry.

Both approaches require a communication channel; if it breaks, consumers cannot get updates.

Push requires the registry to maintain many sessions and heartbeats; pull is simpler but introduces latency based on the polling interval.

Long‑polling (long‑pull) combines advantages: the consumer holds a request open until the registry has changes, reducing latency without constant polling.

Long‑polling saves bandwidth compared to simple polling but still occupies server resources while waiting.

By combining service registration, consumption, high‑availability clustering, and dynamic up/down detection, a complete service registry model is achieved.

Summary

Designing a registry focuses on four points: service registration, consumer discovery, registry high availability, and dynamic detection of service lifecycle changes.