Архитектура бэкенда
Жизненный цикл запроса: тест с выбором ответа
Суть Тест с выбором на синтез по всему жизненному циклу запроса — accept-очереди, порядок middleware как граница безопасности, стоимость сериализации, backpressure и амплификация хвоста при fan-out.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всех семи остановок. Каждый отражает реальный инцидент — не стадию для называния, а симптом, который надо локализовать до одной остановки, плюс механизм, объясняющий его.
Цель
Убедись, что по симптому прыгаешь к нужной остановке: связываешь лимиты accept-очереди, порядок middleware, стоимость сериализации, backpressure и амплификацию хвоста в один рефлекс принятия решения.
Викторина
Completed
Под всплеском трафика клиенты получают connection timeout и reset, но логи приложения полностью пусты — ни 500, ни трейсов обработчика. Какая остановка и почему логи пусты?
Heads-up Исключение выполняется внутри твоего кода, поэтому попадает в логи и обычно возвращает 500. Пустые логи означают, что запрос вообще не дошёл до приложения — отбрасывание выше, в accept-очереди ядра.
Heads-up Сериализация происходит сильно позже accept(), на запросах, которые дошли до кода. Если соединения отвергаются до запуска обработчика, сериализация ни при чём, и для прошедших запросов логи бы остались.
Heads-up Игнорирование backpressure даёт OOM на активно пишущихся ответах — это краш с симптомами роста кучи, а не тихий отказ соединений с пустыми логами во время всплеска.
Викторина
Completed
Security-ревью находит, что один admin-эндпоинт обслуживает неаутентифицированные запросы, хотя auth-middleware реализован, протестирован и зарегистрирован. Наиболее вероятная причина?
Heads-up Попадание в правильный admin-обработчик означает, что роутинг сработал. Сбой в том, что запрос не был аутентифицирован до запуска обработчика — это баг порядка, а не матчинга.
Heads-up Проблема парсинга/формата отвергала бы валидных пользователей (запрет доступа), а не пускала неаутентифицированных. Если пускает всех — auth просто не выполнялся, это вопрос порядка.
Heads-up Роутинг — микросекунды независимо от числа маршрутов, и таймаут не пропустил бы auth молча, а провалил бы запрос. Обработчик просто оказался раньше auth-слоя в порядке регистрации.
Викторина
Completed
Эндпоинт стал на 40% медленнее после роста результата с 50 до 5000 строк, но время запроса к БД не изменилось — те же 8 мс. Куда ушло время и какой первый фикс?
Heads-up Стоимость матчинга не зависит от размера ответа (и это всё равно микросекунды). Размер результата влияет на формирование ответа, а не на поиск обработчика.
Heads-up Accept-очередь ограничивает ожидающие соединения, а не размер ответа. Она отвергает соединения под нагрузкой; она не делает успешный ответ медленнее пропорционально числу строк.
Heads-up Keep-alive влияет на стоимость установки соединения, которая не масштабируется с числом строк в одном ответе. Замедление на 40%, отслеживающее размер payload, указывает на сериализацию.
Викторина
Completed
Стриминговый экспорт даёт OOM только когда клиент скачивает по медленному каналу. Код вызывает res.write() в цикле и игнорирует возвращаемое значение. Каков точный механизм?
Heads-up false не означает провал — данные приняты в буфер. Это сигнал backpressure «притормози», а не «ретрай». Рост — это непрочитанные данные в userland-буфере, а не дублированные записи.
Heads-up GC работает нормально; он просто не может освободить буферы, на которые ещё ссылается очередь ожидающих записей. Эти байты — живые данные, которые потребитель не прочитал, а не мусор.
Heads-up Ретрансмиты нормальны и ограничены TCP-стеком; они не вызывают неограниченного роста кучи. Рост на уровне приложения: скорость производства оторвана от скорости чтения клиента.
Викторина
Completed
Страница продукта делает fan-out на 100 независимых сервисов параллельно и ждёт всех. У каждого p99 = 10 мс (1% шанс, что вызов превысит). Примерно какая доля загрузок страницы превышает 10 мс хотя бы на одном вызове и какой устойчивый фикс?
Heads-up 1% — это частота на вызов. При 100 независимых вызовах и join «ждать всех» шанс, что ни один не медленный — 0.99^100, поэтому медленная доля компаундится до ≈63%. Независимость не защищает, когда ждёшь всех.
Heads-up Амплификация хвоста не линейна. Компаундящееся 1 − (1 − p)^N растёт куда быстрее линейной оценки; при p=1%, N=100 это ≈63%, а не 10%.
Heads-up Ты медленный, если медленный любой один, а не только если все. Ожидание всех означает, что один медленный из 100 задаёт задержку всей страницы — именно это и амплифицирует хвост.
Викторина
Completed
У запроса SLA 1 с. Сервис A (client timeout 1 с) вызывает сервис B (client timeout 1 с). Когда B зависает, A продолжает работать всю секунду после того, как клиент уже сдался. Почему и что это чинит?
Heads-up Длина — не корень проблемы, композиция. Даже хорошо подобранные локальные значения суммируются за SLA без общего пробрасываемого бюджета; фикс — deadline, а не меньшая константа.
Heads-up Клиенты поддерживают таймауты — здесь и A, и B ставят 1 с. Изъян в том, что изолированные таймауты не сворачиваются в один deadline, несомый вниз по цепочке вызовов.
Heads-up Таймауты приложения соблюдаются. Сбой архитектурный: не пробрасывается deadline с остатком бюджета, поэтому внутренние hop'ы переживают терпение вызывающего.
Итог
Сквозная линия юнита — один рефлекс: по симптому прыгай к остановке, которой он принадлежит. Пустые логи под всплеском — accept-очередь (somaxconn) отбросила соединения до запуска кода; неаутентифицированный эндпоинт — порядок middleware, а не логика auth; замедление, отслеживающее размер payload — сериализация; OOM под медленными клиентами — проигнорированный backpressure; медленная страница при здоровых сервисах — амплификация хвоста при fan-out, чинится пробрасываемыми deadline и hedging. Задержка — сумма по всем семи остановкам плюс очереди, поэтому карта превращает слепую отладку в один прыжок.