Every WebSocket server eventually gets a slow client — bad wifi, a suspended mobile app, a browser tab that stopped running its event loop. The server keeps producing messages for it regardless. What happens to those messages is a design decision, and "block until the client catches up" is the wrong one: block the wrong goroutine and you've turned one slow client into an outage for every other connection on the process.
Article one in this series
showed the two-phase pattern — Drain then Shutdown — as the answer to
"what happens to 8,000 open connections when a deploy kills the pod."
This one is about why it needs to be two phases with real machinery behind
each, not a sync.WaitGroup.Wait() and a signal handler. The naive version
— stop accepting connections, wait for every existing one to close on its
own — sounds graceful and has a hole in it big enough to hang your rollout:
a client that's connected but silent, sending and receiving nothing, never
triggers a natural disconnect. Wait for it to leave on its own and you're
not draining gracefully, you're waiting for Kubernetes' own termination
grace period to expire and SIGKILL you anyway — which is exactly the
outcome graceful shutdown exists to avoid.