In what order does a Go service tear down its subsystems, and who closes each input channel?

## Shutdown has a direction A typical service `main` wires several subsystems together: an HTTP entry point, a queue consumer, a pool of handlers behind a channel, and a flusher that everything writes into. When the process is asked to stop, these cannot be torn down in an arbitrary order, and "all at once" is an order too — a bad one. Teardown follows the direction data flows, from the front door to the last thing that persists anything. ### 1. Stop accepting The front of the pipeline goes first. The HTTP side stops taking new connections (its own graceful-stop call handles the requests already in flight), and the consumer loop stops fetching new items — usually because its `select` now sees `ctx.Done()` and returns instead of fetching again. This step is what makes the rest finite. If the front door is still open, every later step is chasing a moving target: you wait for the workers, and more work arrives while you wait. ### 2. Let each sender return, then close its output Every internal channel has a **sending side** and a **receiving side**, and the ownership rule is fixed: the channel is closed by the side that sends on it, after that side has stopped sending. Concretely: ``` senders.Wait() // no goroutine can send on items any more close(items) // safe precisely because of the line above ``` Both halves matter. * **Closed by the sender, not the receiver.** A receiver does not know whether a producer is mid-send. Closing from the receiving side, or from `main` "because shutdown started", races with a send that is already under way; the sending goroutine then crashes the process on a channel that vanished under it. * **After the sender returned, not before.** With several producers, the join has to cover all of them; "one of them noticed the cancellation" is not the same as "none of them will send again". If ownership is genuinely tangled — many senders, no single owner — the honest answer is to change the design so one goroutine owns the close, not to add defensive checks; there is no way to test whether a channel is closed before sending. ### 3. Let the downstream drain Closing the input is not merely a formality; it is the difference between finishing accepted work and dropping it. A stage written as ``` for it := range items { handle(it) } ``` keeps handling until the channel is both closed and empty, then returns. A stage written to return the instant `ctx.Done()` fires abandons whatever is still queued in the channel. Both are legitimate designs, but they are different promises, and shutdown ordering is where the difference becomes visible: items your service already accepted are either completed or silently lost. This is also why the cancellation and the close are not redundant. Cancellation stops the *front*; the close is what tells the *back* that the front is finished. ### 4. Release shared resources last The last group is the things that are not in the data flow at all: a metrics or log flusher, a database handle, an open file, an outbound client. Every subsystem writes into them, so nothing can be closed while any subsystem might still be alive. They come off in the reverse of the order you constructed them, which is the same thing as saying: something built first is depended on by things built later, so it dies last. A flusher is the clearest case. It is not downstream of anything by channel, so following the pipeline never reaches it. It is released after the final `Wait` returns, and its own flush is the last useful work the process does. ## The whole sequence 1. Cancel the root context — the single trigger. 2. Entry points stop accepting. 3. For each stage, front to back: wait for its senders, close its output channel, wait for its receivers. 4. Close shared dependencies, reverse of construction. 5. Return from `main`. ## The two mistakes an interviewer is listening for **Closing everything up front.** "Shutdown started, so let me close all the channels and cancel everything" reverses steps 2 and 3 and turns a graceful stop into a crash, because `main` is not the sender on any of those channels. **Releasing before joining.** Closing the flusher or the database handle right after the cancellation, on the assumption that cancellation means stopped. It does not; only the wait means stopped. ## Why the order is worth writing down The ordering is a property of the wiring, not of any one subsystem, so it lives in exactly one place — the function that constructed everything. When someone adds a fifth subsystem, the question they must answer is where it goes in this sequence: what it accepts, who sends into it, and who depends on it. A service where that question has no owner is one where shutdown quietly stops working the next time it grows.