How do you decide which post-response work in a Go service may outlive the request context?

## Why this is a judgment call rather than an API question The mechanism is easy: `context.WithoutCancel` detaches work from the request's cancellation, and a timeout re-bounds it. The hard part is that detaching is *cheap to write and expensive to be wrong about*, and the cost lands on somebody who is not in the room — the data engineer reconciling audit rows, the finance team matching charges, the compliance owner who has to attest that every access was recorded. A service owner who moves a write off the request path is trading a few milliseconds of tail latency for a small, invisible loss rate. That is a legitimate trade for some work and an unacceptable one for other work, and the line is not technical. ## The classification I use **Best-effort.** Losing an occasional instance changes nothing anyone will ever notice: warming a cache, refreshing a derived value that will be recomputed anyway, emitting telemetry, invalidating something that also has a TTL. These may be detached. They should still be bounded and instrumented, but nobody is harmed by a gap. **Required-but-deferrable.** Somebody will eventually notice: notification emails, webhooks to customers, search index updates. These may leave the request path only if there is a durable handoff — a row committed in the same transaction as the business change, or a message on a broker — with a consumer that retries. A goroutine is not a durable handoff. **Required-and-reconciled.** Audit trails, billing events, anything an auditor samples. These are written inside the request, in the same transaction as the change they describe wherever the storage allows it. If that costs latency, the honest answer is that the latency is the price of the guarantee, and the conversation to have is about making the write cheaper, not about making it optional. ## What detaching actually does and does not buy It is worth being precise, because the fix is often mistaken for a guarantee. A detached context is never cancelled and has no deadline; it still carries the request's values. So the work survives the handler returning and the client hanging up. It does not survive: - **process exit** — deploys are the common case, and a service that deploys ten times a day loses a slice of pending work ten times a day; - **graceful shutdown**, unless you made it wait: the HTTP server's `Shutdown` drains in-flight *handlers*, and knows nothing about goroutines a handler spawned; - **backpressure** — one goroutine per request is unbounded by construction, so a slow dependency converts a traffic spike into memory growth and an ever-longer queue of work that will be lost at the next restart. Any policy that says "we detach it" without answering those three has not been finished. ## The controls that make the policy real **A default, stated as a default.** "Nothing whose absence would be a defect leaves the request path." Defaults that live in a document nobody reads are decoration; this one belongs in the shared helper — if the only easy way to schedule background work is a submission function that takes a bounded worker pool and applies the house timeout, the default enforces itself and `go f(r.Context())` stops appearing in review. **A cap and a shed.** A fixed number of workers and a bounded queue, with a defined behaviour when it is full: block the handler, drop with a counter, or spill to durable storage. Choosing is the point; discovering it under load is not. **Shutdown semantics.** Say explicitly what a rolling deploy waits for. Draining a bounded queue for a few seconds during shutdown is cheap and removes the largest loss source. **Evidence.** Counters for submitted, completed and dropped, per category, plus the error from every failed attempt. Without them, "best-effort" is unfalsifiable and the first anyone hears of a problem is a gap discovered downstream weeks later. ## Who can overrule you, and on what grounds This is the part to say out loud in an interview. The service owner sets the default because they own the latency and the capacity. But the owner of the *data* — audit, billing, compliance — can overrule any classification for their category, because they carry the consequence of a gap, and their requirement is usually not negotiable in the way a latency target is. The workable arrangement is: engineering proposes the classification and provides the numbers (what it costs in tail latency to keep it in the request), the data owner accepts or rejects, and the decision is written down next to the code so the next person does not silently re-litigate it by adding a `go` statement. ## The shape of a good answer Start from the loss model rather than the API. Distinguish latency relief from durability. Name the three things detaching does not survive. Give the controls — default, cap, shutdown, counters — and be explicit that the person who eats the cost of being wrong gets a veto.