Go cannot kill a goroutine, so how do you set your service's shutdown budget when the platform owns the grace period?

## Two owners, one number How long a service may take to exit is owned twice. The **platform** owns the grace period: it asks the process to stop, waits some number of seconds, then kills it outright. It cares because that number multiplies across every instance in every rollout, and it sets how fast a bad release can be replaced. The **service owner** knows what work is in flight and what it costs to lose. Neither can set the number alone, and the service owner can be overruled — which is exactly why the argument has to be made in terms the platform team can act on. ## The Go fact that shapes the whole decision Go has no way to kill a goroutine. Cancellation is cooperative: a goroutine that is inside a blocking call which does not watch a context cannot be shortened at all. So the deadline is not a mechanism for stopping work — it is a mechanism for **abandoning** it. Whatever has not finished when the timer fires is left where it stands, and the process exits. That reframes the design question. Instead of "how long do we need to finish everything", the question is "what must have finished before we are allowed to be abandoned, and how do we make everything else safe to abandon". ## Classify the teardown work Walk the teardown sequence and sort each step: * **Unrecoverable if lost.** A non-idempotent external effect that is half-applied. A record written without its counterpart. These are the only steps that genuinely deserve budget, and the strongest move is usually to remove them from this category — an idempotency key, a two-phase write, a transaction that either commits or does not — rather than to buy more seconds. * **Redone on restart.** An unacknowledged message is redelivered. A batch that was not checkpointed is recomputed. This is the bulk of most services' in-flight work, and it costs a little duplicated effort, not correctness. * **Best effort.** A final flush of buffered logs or metrics. Nice to have, never worth blocking an exit for; give it a small slice at the very end and let it be cut. The budget is the sum of the first group plus margin — not the sum of everything the service happens to be doing. ## Derive the number, do not pick it Work inwards from the grant. If the platform kills at N seconds, the internal deadline is meaningfully below N, because you want your own watchdog to fire first: your exit is attributable and it produces a diagnostic, while an external kill produces nothing. Below that sit the individual step budgets, and each one is measured, not guessed — instrument how long teardown actually takes, publish the distribution, and treat the tail as the design input. That instrumentation is also what converts the conversation with the platform team from opinion into evidence. "We need 90 seconds" is a position. "Our teardown's tail is 12 seconds, 11 of which is one non-idempotent call we are removing this quarter" is a plan. ## When the answer is no Assume the grace period will not be raised for you, and design for that as the normal case. The lever you still own is the size of the requirement: * Shrink the unit of work, so less is ever in flight at once. * Checkpoint mid-work, so an abandoned unit resumes rather than restarts. * Acknowledge later, so an abandoned item is redelivered instead of lost. * Move the unrecoverable step out of the request path entirely. Every one of these makes the service cheaper to kill, which is worth more than a longer grace period: a service that is safe to abandon at any instant is also safe during a crash, a node failure or an out-of-memory kill — none of which give you a grace period at all. ## Own the kill path The last part of the judgment is cultural. If being killed at the deadline is treated as a bug, every incident produces pressure to raise the grace period, and the number ratchets up across the fleet. If it is treated as a supported path — recovery on the next start is tested, duplicate delivery is handled, the exit is logged with the step that was outstanding — the number can stay small, rollouts stay fast, and the service tolerates the failures that were never going to be graceful. ## What a strong answer sounds like It names the constraint (the grant, and Go's inability to kill a goroutine), classifies the work rather than treating it as one lump, derives the internal deadline from measurement, offers a concrete alternative to a longer grace period, and accepts the overrule without leaving the service unsafe. It does not open with a number.