Service discovery: names, health and front doors

Discovery maps a logical service to candidate endpoints. DNS offers a common naming interface; a registry offers explicit membership and metadata. They can coexist: a registry may expose DNS. Neither interface makes returned endpoints permanently healthy.

With client-side discovery, the client resolves membership and chooses a destination. Each client library needs selection, refresh and failure handling. Direct calls avoid an extra proxy hop, but client implementations can behave differently.

With server-side discovery, clients call a stable front door; a proxy or load balancer selects the backend. This centralizes routing behavior but creates another capacity and failure boundary. Run the front door redundantly and monitor its discovery freshness.

Here, detection takes up to 10 seconds; a just-refreshed cache retains the endpoint for another 30. About 40 seconds bounds stale discovery only if TTL is honored, one failed check removes the endpoint, publication is immediate, and stale answers are never served. Existing connections have separate lifetimes.

Remove an instance from new routing before terminating it. Allow discovery propagation and drain in-flight requests. A process can be alive but unable to serve because a dependency is unavailable. Timeouts and bounded retries still matter after a healthy lookup.

An API gateway is often a reverse proxy with API policies. These are roles, not necessarily separate boxes. Authenticate and authorize at appropriate trust boundaries; a registry entry is not permission to call a service. Gateway policy and service authorization must agree.

Try a fresh variant, then score at least 80% on the mastery check. Wrong answers link back to the teaching step.