Interview Question: Designing a Service Registry

Problem Scenario

In a two‑system setup (Order system as consumer, Product system as provider) calling a service via a hard‑coded address, a configuration file, or an Nginx proxy works only when a single instance is deployed. In production each service runs many instances; when a provider instance goes down or a new instance is added the static approaches break.

Roles

Provider = Product system, Consumer = Order system.

Design Goals

Service registration mechanism.

Service discovery for consumers.

High availability of the registry.

Dynamic detection of service up/down events.

Service Registration

Providers push their service metadata (service name and instance address) to the registry. The registry can store the service list in three typical ways: in‑memory, a relational/NoSQL database, or a third‑party cache (e.g., Redis).

When a consumer needs a service address it queries the registry with the service name (key) and receives the current list of provider instances (value).

Service Consumption

Consumers retrieve the address list from the registry and cache it locally. The key is the service name; the value is the list of instance addresses.

Registry High Availability

Multiple registry nodes are deployed as a cluster. Consumers only need to know a single cluster‑url that load‑balances to the registry nodes.

Dynamic Detection of Service Up/Down

The registry performs heartbeat checks ( heartBeat) on each provider at a configurable interval. If a heartbeat fails, the registry removes the corresponding address from the service list.

Two communication models keep the consumer cache up‑to‑date:

Push : the registry actively pushes updated service lists to consumers. This requires the registry to know each consumer’s address or a consumer‑exposed callback API; transport can be HTTP or a socket listener.

Pull : the consumer periodically polls the registry (e.g., every 30 seconds). This is simple but introduces a delay equal to the polling interval.

An optimized variant is long‑polling (or long‑pull). The consumer sends a request that the server holds until a change occurs or a timeout expires.

Advantages : simple implementation, bandwidth saving compared with frequent polling. Disadvantages : the server holds connections, consuming resources and reducing overall handling capacity. Typical use case : early real‑time applications such as web IM chat.

Both push and pull require a reliable communication channel; if the channel breaks the consumer cannot obtain the latest service list.

Core Model Summary

Providers register service metadata to a registry.

Consumers discover providers by querying the registry with a service name.

The registry is deployed as a HA cluster accessed via a single cluster‑url.

Heartbeat detection removes stale provider entries.

Cache synchronization can be achieved via push, pull, or long‑polling, each with trade‑offs in resource usage and latency.