Дренаж и порядок выключения: переверни граф зависимостей

Маршрутизация сдренирована, SIGTERM пришёл, и твой обработчик вызывает ту единственную строку, что показывает каждый туториал: server.close(). Ты ждёшь, что процесс свернётся и выйдет. Вместо этого он висит, пока grace period не истечёт, и его всё равно SIGKILL’ят — а на другом деплое горстка запросов падает с ошибками database-connection-closed во время дренажа. Тебя кусают две отдельные истины. Первая: server.close() останавливает сервер от приёма новых соединений, но не закрывает уже открытые и простаивающие keep-alive соединения, так что эти сокеты держат сервер «занятым», и колбэк закрытия никогда не срабатывает. Вторая: когда ты всё же сумел выключиться, ты закрыл пул базы тем же махом, что и HTTP-сервер — но запрос, ещё в полёте, потянулся к пулу мгновением позже и нашёл его исчезнувшим. Чисто дренировать — это не один вызов; это закрытие правильных вещей в правильном порядке и ограничение всего этого так, чтобы один застрявший запрос не держал процесс в заложниках.

server.close() необходим, но недостаточен

server.close() делает ровно одно: останавливает сервер от приёма новых соединений и срабатывает колбэком, как только все существующие соединения закончились. Ловушка — keep-alive. HTTP/1.1 держит соединения открытыми по умолчанию (а HTTP/2 мультиплексирует поверх одного долгоживущего), чтобы клиенты могли переиспользовать сокет под много запросов. После того как запрос закончился, его соединение сидит простаивающим, но открытым, ожидая следующего запроса. server.close() не тронет эти простаивающие keep-alive сокеты — с его точки зрения они всё ещё «активные соединения» — так что колбэк не срабатывает, и процесс висит до SIGKILL.

Фикс — дренировать keep-alive намеренно:

• Сигналь клиентам перестать переиспользовать сокет. Шли Connection: close на ответах во время выключения, чтобы каждый клиент закончил текущий запрос и переподключился в другом месте (к здоровому инстансу), вместо того чтобы держать сокет открытым.
• Принудительно закрой простаивающие сокеты. Отслеживай открытые соединения и уничтожай простаивающие (не в середине запроса) немедленно, давая активным закончиться. Экосистема Node оборачивает это в хелперы; более новый рантайм выставляет server.closeIdleConnections() и server.closeAllConnections() ровно для этого.

Цель дренажа: каждый запрос в полёте получает шанс закончиться и ответить, а каждое простаивающее соединение закрывается оперативно, чтобы сервер реально достиг нуля и вышел.

Закрывай ресурсы в обратном порядке зависимостей

Когда HTTP-слой сдренирован, ты разбираешь остальное — и порядок не произволен. Правило — обратный порядок зависимостей: выключай в порядке, обратном запуску, чтобы ничто не выдёргивалось из-под того, чему оно ещё нужно. При запуске ты открываешь базу, затем кеш, затем начинаешь принимать HTTP. При выключении переворачиваешь это:

1. Останови HTTP-сервер / сдренируй запросы в полёте — новое не может прийти, существующие запросы заканчиваются.
2. Останови фоновые воркеры и сбрось очереди — дай джобам в процессе завершиться или сделать чекпоинт.
3. Закрой хранилища последними — пул базы, затем Redis, затем любой другой даунстрим.

Причина конкретна: запрос в полёте, в середине дренажа, может ещё выпустить запрос в базу. Если ты закрыл пул базы до того, как этот запрос закончился, запрос упирается в закрытый пул, и он падает — ты превратил грациозный дренаж в ту самую потерю запросов, которую предотвращал. Хранилища — самая глубокая зависимость, так что они закрываются последними, после всего, что может их использовать. Закрытие пула Postgres само дренирует: pool.end() ждёт закрытия простаивающих клиентов и обрывает активные запросы после таймаута.

Страховочный таймаут

Дренаж может зависнуть. Запрос может застрять на медленном даунстриме, keep-alive клиент может никогда не прислать Connection: close, воркер может заклинить. Если ты просто await’ишь дренаж вечно, ты пролетаешь grace period и получаешь SIGKILL посреди уборки — теряя ровно то состояние, что пытался сбросить. Так что каждое продовое выключение оборачивает дренаж в страховочный таймаут (также force-shutdown или shutdown-watchdog): запусти таймер на меньше, чем grace period, и если дренаж не завершился к его срабатыванию, залогируй громко и форсь выход (process.exit(1)) на своих условиях. Самоинфликтный, залогированный выход за секунду до SIGKILL строго лучше, чем ядро, выдёргивающее вилку, потому что ты контролируешь код выхода и можешь сбросить логи и метрики первыми.