The equipment-availability service has moved to a new server. Its health check passes and the registry contains the new address. Yet staff still see errors: one application has cached the previous address, while another keeps an old connection open. Both are calling a service that is no longer there.
Service Discovery finds current instances through a stable name. Registering a new address is only part of the job. The change must reach the applications using it, and that is often where automation stops short of removing manual work.
The name stays; the instances change
A client needs the availability service, not a particular machine. It uses a logical name. It may then receive a list of instance addresses and choose one itself, or contact a stable entry point behind which the infrastructure selects an instance.
A regular Kubernetes Service, for example, gives a changing group of instances a stable address. DNS can return that address rather than every application's IP. A headless Service works differently: clients receive the selected Pods' addresses. The Kubernetes DNS documentation explains the distinction. “We use DNS” does not describe the complete request path.
Discovery identifies possible destinations; balancing selects where particular work goes. They are related, not identical. The platform, a registry or the applications themselves may maintain the list. More client-side choice means more client-side responsibility for updates and failures.
First establish which service a record represents
Every record has an origin: who registered it, which environment it belongs to and how its freshness is established. An incorrect selector can put a test instance into a production list. An abandoned entry can leave clients pointing at a machine that now serves something else.
Permissions to register and modify records matter alongside registry availability. Environment names need predictable separation, and instances need an explicit registration lifecycle. Consul's DNS documentation provides one example of discovery queries.
Finding an address is not authorisation. The client must still authenticate the other side and be entitled to perform the operation. Locating an internal name should not grant an employee access to private equipment records.
Being listed is different from being ready
A process may have started but still be loading reference data. Sending requests immediately causes avoidable failures. Readiness should reflect the work the instance will receive, not merely an open network port.
Nor should every downstream failure remove all instances from service. Restarting applications will not restore an unavailable shared supplier. Decide what work the applications can still perform. Health Checks explores the distinction between readiness and restarting a process.
Platforms can also have exceptions. Kubernetes endpoint information includes readiness and termination conditions, and some settings publish instances that are not yet ready. Inspect the deployed configuration rather than assuming every published address is safe. The EndpointSlice documentation describes these conditions.
Removing a record does not end every connection
Several delays sit between a registry update and the last request to the old instance. Changes must propagate, client caches must refresh, and existing connections may remain open. Updating DNS does not automatically close them.
A shorter cache lifetime helps only where the client actually honours it. It also generates more lookups. Check library and connection-pool behaviour rather than assuming a short DNS lifetime makes a move instantaneous.
For planned removal, stop directing new work to the instance and allow agreed operations to finish. A sudden failure offers no such grace period. Clients need bounded waiting and safe failure handling. A replacement address does not resolve an unknown result: the earlier request may have completed before its response was lost. Retries still need appropriate idempotency.
A stable name does not make application versions compatible. During an update, the list may contain both versions. If they interpret the contract differently, correct routing will simply distribute the failures. Support mixed-version operation or separate incompatible interfaces explicitly.
What if discovery itself is unavailable?
An established client may continue using known addresses while a newly started application cannot find any service at all. Testing existing connections alone misses that distinction. Exercise both client startup and refresh behaviour.
Last-known addresses can sometimes be used temporarily, but the permitted age and conditions must be explicit. A stale destination may no longer work, or access to the previous instance may have been revoked. An unlimited cache and unlimited lookup retries fail differently; neither is a universal recovery policy.
Diagnosis needs the logical name, chosen address, last refresh and failure stage. Did name resolution succeed? Was a connection established? Did the application reject the call? Without that evidence, a permissions or configuration issue becomes another report that “the network sometimes fails”.
When has the replacement actually finished?
Replace an instance while an ordinary client continues working. Check discovery of the new destination, removal of the old one, an unfinished request and startup of a new consumer. Then temporarily restrict discovery and verify the agreed fallback behaviour.
Where an existing platform Service or load balancer already does this, a separate registry may add little. The benefit is fewer manual client changes and a predictable replacement process. A successfully updated entry in an administration screen is only an intermediate result.