ELI5 · Distributed systems

Service discovery.

A live company directory services check to find each other, instead of memorising addresses that keep changing.

In a system of many services, the orders service needs to call the payments service. But in the cloud, services move: instances start, stop, scale up, and get fresh addresses all the time. Hard-coding an address is hopeless — it is stale within minutes.

Service discovery is the live company directory that fixes this. Each service registers itself when it starts ("payments is now at this address"), and callers look up "where is payments?" to get a current, healthy address. Nobody memorises numbers; everybody asks the directory.

  1. Wrong number again.
    stale! 10.0.0.7 10.0.4.2?
    1

    In the cloud, addresses keep changing — a hard-coded one is stale within minutes.

  2. Payments, checking in.
    REGISTRY payments register
    2

    So each service registers with Dee’s directory the moment it starts up.

  3. dropped
    3

    Dee health-checks the entries and quietly drops any that stop responding.

  4. Where’s payments?
    orders where? REGISTRY
    4

    A caller just asks the directory by name instead of memorising a number.

  5. Here — this one’s up.
    10.0.4.2
    5

    Dee hands back a current, healthy address to call.

  6. DIRECTORY payments→…orders→…search→… ask by name, always current
    6

    Nobody memorises numbers; everyone asks by name, and the map is always current.

A staff directory that updates itself: register on start, look up by name, drop the dead.

Why it is essential in the cloud

Static addresses assume machines stay put, which is exactly what cloud and container platforms do not do — they autoscale, reschedule, and replace instances constantly. A registry keeps an up-to-date map of what is running where, and crucially runs health checks so callers are only handed addresses that are actually alive. It pairs naturally with load balancing: pick one of the healthy instances the directory returns.

Client-side vs server-side

There are two common shapes. In client-side discovery, the caller queries the registry itself and picks an instance. In server-side discovery, the caller just talks to a fixed load balancer or proxy that consults the registry on its behalf and forwards the request. Kubernetes leans on the latter, giving each service a stable internal name that resolves to whatever healthy pods currently back it, so callers never deal with raw instance addresses at all.

The real version How service discovery works →
Found this useful?