An instance deregisters itself from the service registry before it exits, yet callers keep sending it requests for tens of seconds afterwards. What determines the length of that window, and how do you shut the instance down without dropping those requests?

## Deregistration is a write, not a stop The instinct behind the bug is that removing yourself from the registry is like closing a valve. It is not. It is an update to a piece of shared state that a number of independent parties read on their own schedules. Nothing about that write reaches out and stops a caller mid-request, and nothing about it closes a socket. Until every reader has observed it, you are still, from their point of view, a member. ## The window, term by term Write down the terms and the window stops being mysterious: 1. **Apply and replicate.** The registry accepts the write and makes it durable. If it is replicated, the caller may be reading a replica that has not converged yet, so the relevant figure is not "when the write returned" but "when the replica this caller reads reflects it". 2. **Caller refresh.** How the caller learns. A polling client learns on its next poll — worst case, one full interval. A watching or streaming client learns when the push is delivered, which is fast but not instantaneous and not guaranteed while it is reconnecting. 3. **Caller-side cache.** Many discovery clients keep a local snapshot of the member list, deliberately, so that a registry blip does not black-hole traffic. That cache has its own refresh period, which stacks on top of the previous term. 4. **Connections already open.** Even after the caller drops you from its member list, a connection pool may hold an established socket to your address. Membership changes generally do not tear down live connections, so requests keep arriving on them until the pool rebuilds. 5. **In-flight work.** Requests you have already accepted and not yet answered. The total is the number your shutdown sequence has to respect. It is a property of the platform — of the registry's convergence and the callers' refresh settings — and not of your application code, which is exactly why teams that tune only the application keep seeing the errors. ## The shutdown protocol that works The correct order is: 1. **Deregister** (or otherwise mark yourself as leaving) while still fully serving. 2. **Pause** — keep accepting and answering requests normally for longer than the window above. This lame-duck period is doing the real work: it exists purely so callers can converge while you are still able to answer them. 3. **Stop accepting new work** — stop advertising, refuse new connections. 4. **Finish in flight**, bounded by a deadline so a stuck request cannot block the exit indefinitely. 5. **Exit.** Two details separate an implementation that works from one that only looks right. The pause must be *serving*, not sleeping with the listener closed — a paused-but-closed instance produces exactly the connection failures you were trying to avoid. And a shutdown must never answer arriving requests with errors as a form of "draining": that converts a clean handover into visible failures and, worse, into failures that look like the dependency being broken. ## Planned versus unplanned removal The entire sequence above only exists when the process gets to run it. If an instance is killed hard, loses its host, or wedges, it never deregisters, and its entry is removed only when the registry decides the lease has lapsed — heartbeat interval multiplied by a missed-beat threshold, plus reaping. That is typically far longer than the planned path, and it is why callers must still tolerate connection failures to instances that are currently listed. The two paths are complementary: the lease is a safety net for the case where nobody told the registry anything, not the mechanism you rely on for a rolling deploy. ## Why you cannot simply tune the window to zero Each term resists shrinking. Shorter caller poll intervals multiply read load on the registry and, at scale, turn every deploy into a thundering read. Shorter heartbeat intervals raise write load and make the registry more likely to remove a healthy instance during a brief network blip — you trade staleness for stability, and evicting healthy members is much worse than serving one for a few extra seconds. Caller-side caching, which lengthens the window, exists on purpose so that a registry outage degrades gracefully rather than emptying every member list at once. So the practical target is not zero. It is: know the number, make the lame-duck pause exceed it with margin, and make callers resilient to the residual. ## How to present this in an interview Say "deregistration is a write, not a stop", enumerate the terms, and then give the ordering. If you add one more sentence, make it the asymmetry between a clean exit and a crash — that is the detail that shows you have watched a deploy do this to a production service.