Build fluency in the vocabulary of finishing in-flight requests before a process actually exits.
0 / 5 completed
1 / 5
At standup, a dev mentions a process catching the termination signal and finishing its in-flight requests before actually exiting, rather than being killed mid-request. What is this practice called?
Graceful shutdown has a process catch the termination signal, typically SIGTERM, and finish its in-flight requests before actually exiting, rather than being killed abruptly mid-request. Graceful degradation is a different concept about reducing functionality under load while still running, not about the shutdown sequence itself. This finish-in-flight-work-first behavior is what prevents a routine deploy or scale-down from dropping requests a client is actively waiting on.
2 / 5
During a design review, the team wants a load balancer to stop sending new requests to an instance that's shutting down, while still letting that instance finish requests already in progress. Which capability supports this?
Connection draining coordinated with the shutdown sequence stops the load balancer from sending new requests to an instance that's shutting down, while still routing the already-in-flight requests through to completion on that same instance. Continuing to send new requests to a shutting-down instance risks those new requests being dropped the moment the process actually exits. This draining coordination between the load balancer and the instance's own shutdown handler is what makes a graceful shutdown actually effective end to end.
3 / 5
In a code review, a dev notices a shutdown handler waiting for all in-flight requests to complete, but only up to a bounded timeout, after which it force-exits regardless. What does this represent?
A bounded grace period balances letting in-flight requests complete against the risk of the shutdown hanging indefinitely if one request never finishes, for instance because it's stuck waiting on a downstream dependency that's itself unhealthy. A cache eviction policy is an unrelated concept about discarding cached data. This bounded timeout is what keeps a graceful shutdown from turning into an ungraceful hang during an already time-sensitive deploy or scale-down event.
4 / 5
An incident report shows requests were dropped mid-response during every deploy, because the process was killed with SIGKILL immediately rather than being given a chance to finish requests already in progress. What practice would prevent this?
Handling SIGTERM to drain in-flight requests within a bounded grace period before actually exiting lets a process finish the work a client is already waiting on, instead of dropping it the instant the process is asked to stop. Continuing to kill the process immediately with SIGKILL is exactly what caused the dropped mid-response requests in this incident, since SIGKILL gives a process no opportunity to clean up at all. This graceful handling of the termination signal is a baseline requirement for any service deployed with rolling updates.
5 / 5
During a PR review, a teammate asks why the team implements explicit graceful shutdown handling instead of just trusting the load balancer's own retry logic to resend any request that gets dropped mid-response. What is the reasoning?
A load balancer can safely retry a request that never actually reached the backend, but not one that was already partially processed and had a side effect, such as a payment being charged, since blindly retrying that request risks a duplicate charge. Graceful shutdown prevents that scenario from occurring in the first place by letting the in-flight request finish instead of being interrupted mid-processing. The tradeoff is the added implementation complexity of correctly handling the termination signal and bounding how long the process waits before it must exit anyway.