Проследи один запрос: каждый юнит на одном пути кода

Чистейший способ увидеть семь механизмов как одну систему — перестать говорить о них абстрактно и проследить один запрос весь путь вниз. Возьми конкретный: POST /payments, списать с карты, записать результат. Этот запрос не посещает один юнит — он касается всех их, по порядку, на одном пути кода. Он приходит на сокет, что юнит lifecycle научил тебя принимать и парсить. Он проходит через цепочку middleware, что аутентифицирует его и стартует таймаут, с зависимостями, поданными DI-контейнером. Обработчик бежит на event loop, что не должен блокироваться, так что вызов БД асинхронен; этот вызов одалживает соединение из пула; соединение пула говорит с платёжным провайдером через circuit breaker; запись, что он делает, охранена ключом идемпотентности, так что ретрай не может списать дважды. И под всем этим обработчик graceful shutdown ждёт — если SIGTERM приземлится, пока этот запрос в полёте, каждый слой, что он коснулся, должен размотаться в правильном порядке. Один запрос, семь юнитов, один непрерывный путь. Проследи его раз — и тезис «система, не стопка» из прошлого урока перестаёт быть лозунгом и становится вещью, на которую можно показать пальцем.

Счастливый путь, слой за слоем

Проследи POST /payments от сокета до ответа — и юниты предстают как стопка слоёв, каждый передаёт следующему:

1. Приём и парсинг (lifecycle). Сервер принимает соединение, читает запрос с сокета, парсит заголовки и тело. Backpressure и лимиты размера тела живут здесь — кривое или раздутое тело отвергается до того, как стоит хоть что-то даунстриму.
2. Middleware и DI. Запрос проходит через цепочку: логирование, auth, rate-limit и, что критично, место, где бюджет таймаута ставится на весь запрос. DI-контейнер подаёт обработчику его зависимости — платёжный клиент, репозиторий — уже сконструированные и заскоупленные под этот запрос.
3. Обработчик на event loop (async I/O). Обработчик бежит, не блокируя loop. Каждый I/O-вызов await’ится, так что пока этот запрос ждёт БД или провайдера, тот же loop обслуживает тысячи других запросов.
4. Одолжить соединение (пул). Запись в БД нуждается в соединении, так что обработчик берёт одно из пула — с таймаутом получения, так что насыщенный пул падает быстро, а не висит вечно.
5. Вызов провайдера через breaker. Списание идёт к внешнему платёжному провайдеру, обёрнутое в circuit breaker и его собственный таймаут. Если провайдер падает, breaker коротит и обработчик берёт свой фолбэк, а не наваливает сверху.
6. Записать идемпотентно. Результат персистится под ключом идемпотентности, так что если клиент переретраит тот же POST, сервер вернёт исходный результат, а не спишет дважды.
7. Ответить, затем shutdown ждёт. Ответ пишется обратно. Если SIGTERM пришёл посреди списания, обработчик shutdown держал дверь: он перестал принимать новые запросы, держал этот живым и снесёт пул и loop только когда этот запрос ответит.

Бюджет таймаута пронизывает всё это

Единая нить, что связывает эти слои, — дедлайн. Таймаут, поставленный в middleware (шаг 2), не только для обработчика — он должен быть разделён между всем даунстримом. Таймаут получения из пула, таймаут вызова провайдера и таймаут записи в БД все должны влезть внутрь общего бюджета запроса, с запасом. Если бюджет запроса 3 секунды, нельзя дать вызову провайдера 3-секундный таймаут, потому что тогда медленное получение плюс медленная запись пролетают дедлайн без времени ответить. Это урок про хвост латентности из юнита lifecycle, и урок про таймаут получения из юнита пулинга, и урок про таймаут вызова из юнита breaker, все примирённые на одном запросе: бюджеты вложены, не независимы, и должны суммироваться меньше целого.

Один путь, один порядок

Заметь, порядок вынужден, не произволен. Ты парсишь до маршрутизации, получаешь соединение до его использования, ставишь breaker вокруг вызова, что он охраняет, и пишешь идемпотентно до ответа. И shutdown разматывает этот же граф в обратную — перестать принимать, дренировать в полёте, затем закрыть пул последним — что ровно правило обратного порядка зависимостей из юнита graceful shutdown. Путь запроса и путь shutdown — один и тот же граф зависимостей, прочитанный в противоположных направлениях.