Skip to main content

Service Discovery

In a system with a handful of services and a static IP address for each, one service can just hardcode where another one lives. That stops working the moment instances scale up and down, get rescheduled to different machines, or fail and get replaced — the exact address of "the orders service" is now constantly changing, and every caller needs a way to find the current, correct set of addresses without being redeployed every time it shifts. Service discovery is that mechanism: a way for services to find each other's current network location dynamically instead of by hardcoded configuration.

The service registry​

The central piece is a service registry — a database of which service instances currently exist and where they are, kept accurate by Heartbeats: each instance registers itself on startup and sends periodic heartbeats to prove it's still alive, and the registry removes any instance whose heartbeat has gone silent past the timeout, exactly the mechanism that lesson describes feeding into "deregister an instance so it stops being handed out to callers."

System Design Lab

Client-side vs. server-side discovery​

There are two shapes this lookup can take, and the difference is about where the routing decision happens:

  • Client-side discovery — the calling service queries the registry directly, gets back a list of healthy instances, and picks one itself (often with its own load-balancing logic). Fewer moving parts and one less network hop per call, at the cost of every client needing registry-aware logic built in.
  • Server-side discovery — the caller sends its request to a stable, well-known endpoint (a load balancer or an API Gateway) that itself queries the registry and forwards the request. The caller stays completely unaware that discovery is even happening, at the cost of an extra hop and a component that itself needs to be highly available.

Server-side discovery is the more common default in practice specifically because it keeps discovery logic out of every client — an API gateway or load balancer that already sits in front of a service is a natural place to also own registry lookups, rather than teaching every single caller how to talk to the registry directly.

DNS-based discovery: the simplest version​

Some form of service discovery already happens every time a client resolves a hostname via DNS — DNS is a (slow-changing) service registry, mapping a name to current IP addresses. The reason dedicated service discovery systems (Consul, etcd, ZooKeeper, Kubernetes' built-in discovery) exist on top of plain DNS is speed and precision: DNS records typically change and propagate on the order of seconds to minutes (DNS caching and TTLs work against fast updates), while a service registry built for this purpose can reflect an instance disappearing within a heartbeat interval — often sub-second — which matters a great deal when instances are churning constantly in an auto-scaled or container-orchestrated environment.

Why this becomes unavoidable with microservices​

A Microservices Architecture is exactly the scenario that makes hardcoded addresses untenable: dozens or hundreds of independently deployed, independently scaled services, each with instances that come and go constantly as they're deployed, scaled, and replaced. Service discovery is the piece of infrastructure that makes that churn invisible to every caller — without it, every deployment or auto-scaling event would require manually reconfiguring every service that talks to the one that changed.

Why this matters in an interview​

Any design with more than a couple of independently-scaled services should name service discovery explicitly, rather than leaving "service A calls service B" as if B's address were fixed and known in advance. Being specific about client-side vs. server-side discovery — and why one fits the design better — is a concrete way to show you've thought about how the pieces actually find each other, not just what they do once connected.

Client-side vs. server-side discovery: pros and cons​

Server-side discovery

  • Callers stay completely unaware that discovery is happening at all
  • Discovery logic lives in one place instead of being duplicated across every client
  • Easier to add cross-cutting behavior (retries, circuit breaking) at the same layer

Client-side discovery

  • Every client needs its own registry-aware lookup and load-balancing logic
  • Registry client libraries have to exist (and be kept current) for every language in use
  • Harder to add cross-cutting concerns without duplicating logic in each caller

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.