Learn the vocabulary of looking up a service's current location instead of hardcoding it.
0 / 5 completed
1 / 5
At standup, a dev mentions services looking up another service's current network location from a shared registry at request time, rather than a hardcoded IP address baked into configuration. What is this mechanism called?
Service discovery has services look up another service's current network location from a shared registry at request time, rather than depending on a hardcoded IP address baked into static configuration that quickly goes stale as instances are added, removed, or rescheduled. Load balancing distributes traffic across a set of instances that are already known, which assumes the discovery problem has already been solved. This dynamic lookup is what makes a system resilient to instances changing location constantly, which is the norm in a container-orchestrated or auto-scaled environment.
2 / 5
During a design review, the team compares a client directly querying the registry itself to find a healthy instance, versus a client simply calling a fixed address and letting a server-side proxy handle the lookup. What does the second approach represent?
This is server-side service discovery, where the lookup and routing complexity lives behind a proxy instead of being duplicated inside every client, so a client only ever needs to know one fixed address. Client-side service discovery instead requires every client to implement its own registry-lookup logic directly. This split is a genuine architectural choice, trading off where the discovery complexity lives and how much logic every individual client needs to carry.
3 / 5
In a code review, a dev notices a service registering itself with the discovery registry on startup and explicitly deregistering itself as part of its shutdown sequence, rather than just disappearing when the process exits. What does this represent?
This is registry lifecycle hygiene ensuring a terminated instance is promptly removed from the pool of routable instances, rather than lingering in the registry as a stale, dead entry that other services might still be routed to. A read replica describes an unrelated database deployment pattern. Explicit deregistration on shutdown, paired with health checks that catch an instance that dies unexpectedly without deregistering cleanly, is what keeps the registry an accurate, trustworthy source of truth.
4 / 5
An incident report shows requests kept being routed to an instance that had already been terminated during a scale-down, because the registry still listed it and no health check had caught the stale entry. What practice would prevent this?
Combining prompt deregistration on shutdown with active health checks ensures the registry removes a stale entry even if the explicit deregistration step is ever missed, for instance because the instance crashed abruptly rather than shutting down gracefully. Relying solely on explicit deregistration, with no health check as a backstop, is exactly what let requests keep routing to an already-terminated instance in this incident. This combination of graceful deregistration and active health checking is the standard defense against a stale registry entry.
5 / 5
During a PR review, a teammate asks why the team adopts dynamic service discovery instead of just hardcoding each service's IP address in configuration, which is simpler to reason about. What is the reasoning?
A hardcoded IP address goes stale the moment an instance is rescheduled, scaled, or replaced, which happens routinely in a container-orchestrated or auto-scaled environment, leaving every client with an outdated location the instant that happens. A dynamic registry keeps every client's view of a service's location current automatically, without requiring a config change and redeploy every time an instance moves. The tradeoff is the added infrastructure dependency of running and keeping the registry itself healthy and available.