Мок-собеседование по Node.js

Node.js выполняет JavaScript в одном потоке. Как он обрабатывает тысячи одновременных запросов?

Что должно быть в сильном ответе:JavaScript выполняется в одном потоке, но I/O неблокирующий: сокеты Node отдаёт ОС (epoll, kqueue, IOCP), а часть операций, например работу с файловой системой, в пул потоков libuv. Когда операция завершается, колбэк встаёт в очередь, и event loop его выполняет. Для I/O-нагрузки это работает отлично, но одна долгая CPU-задача блокирует все остальные запросы.

Чем отличаются process.nextTick, setImmediate и setTimeout(fn, 0)?

Что должно быть в сильном ответе:Колбэки process.nextTick выполняются сразу после текущей операции, раньше микротасок промисов и до продолжения event loop. setTimeout(fn, 0) срабатывает в фазе timers минимум через 1 мс, а setImmediate в фазе check сразу после poll. Внутри I/O-колбэка setImmediate всегда сработает раньше таймаута, а в основном модуле порядок не гарантирован. Рекурсивный nextTick может «заморить» I/O.

Чем отличаются CommonJS и ES-модули в Node.js?

Что должно быть в сильном ответе:CommonJS использует require и module.exports, загружается синхронно и используется по умолчанию для .js-файлов без "type": "module". ES-модули используют import/export, статически анализируются, поддерживают top-level await и включаются через .mjs или "type": "module". В ESM по умолчанию нет __dirname и require (вместо них import.meta.dirname или import.meta.url), а свежие версии Node умеют делать require() синхронных ES-модулей.

Как обрабатывать ошибки в колбэках, промисах и async/await?

Что должно быть в сильном ответе:Колбэки в Node построены по принципу error-first, поэтому сначала проверяете аргумент err, а потом результат. У промисов есть .catch, а с async/await оборачиваете await в try/catch или даёте ошибке подняться до централизованного обработчика. Забытый await или отсутствующий catch приводит к unhandled rejection, который с Node 15 по умолчанию роняет процесс.

Что такое middleware в Express и почему важен их порядок?

Что должно быть в сильном ответе:Middleware это функция (req, res, next), которая выполняется в порядке регистрации и может изменить запрос, завершить ответ или вызвать next(), чтобы передать управление дальше. Порядок важен: парсеры тела и авторизация должны стоять до роутов, а обработчик ошибок с четырьмя аргументами (err, req, res, next) идёт последним. В Express 5 отклонённые промисы из async-обработчиков автоматически попадают в обработчик ошибок.

Объясните стримы и backpressure. Что будет, если игнорировать backpressure?

Что должно быть в сильном ответе:Стримы обрабатывают данные по частям, а не грузят всё в память. Backpressure это сигнал, что потребитель медленнее источника: write() возвращает false, когда буфер превысил highWaterMark, и источник должен ждать события drain. Если это игнорировать, данные копятся в памяти, и процессу может не хватить heap. stream.pipeline (или его версия на промисах) учитывает backpressure, пробрасывает ошибки и закрывает все стримы при сбое.

Сравните Promise.all, Promise.allSettled, Promise.race и Promise.any. Когда что использовать?

Что должно быть в сильном ответе:Promise.all резолвится, когда все успешны, и отклоняется на первой ошибке, поэтому подходит, когда нужен каждый результат. allSettled ждёт все и возвращает статус каждого, это удобно для пакетных задач, где частичный сбой допустим. race завершается первым завершившимся промисом, обычно для таймаутов, а any возвращает первый успех и падает, только когда упали все. Ни один из них не отменяет оставшуюся работу, для настоящей отмены передают AbortSignal.

Что может заблокировать event loop и как это обнаружить и исправить?

Что должно быть в сильном ответе:Блокирует синхронная CPU-работа: тяжёлые циклы, JSON.parse или stringify больших данных, синхронные вызовы fs или crypto и катастрофический backtracking в регулярках. Обнаруживают по метрике задержки event loop (perf_hooks.monitorEventLoopDelay), через APM или CPU-профиль. Исправляют выносом CPU-работы в worker threads или отдельный сервис, разбиением на части, стримингом больших данных и асинхронными API.

Как найти и исправить утечку памяти в Node.js-сервисе?

Что должно быть в сильном ответе:Сначала убедиться, что это утечка: heap стабильно растёт между циклами GC при постоянной нагрузке, а не выходит на плато. Дальше снять два-три heap snapshot с интервалом (через --inspect, DevTools или --heapsnapshot-signal) и сравнить, какие объекты растут и что их удерживает. Типичные причины: неограниченные кэши или Map в памяти, листенеры, которые не снимаются, замыкания с большими объектами и неочищенные таймеры. Исправление: ограничить кэш или добавить TTL, снимать листенеры и проверить нагрузочным тестом.

Как реализовать graceful shutdown для HTTP-сервиса?

Что должно быть в сильном ответе:По SIGTERM перестаёте принимать новые соединения через server.close(), помечаете сервис как not ready, чтобы балансировщик перестал слать трафик, и даёте завершиться текущим запросам. Затем закрываете простаивающие keep-alive соединения, дочитываете очереди и закрываете пулы БД и другие клиенты. Жёсткий таймаут принудительно завершает процесс, если что-то зависло, чтобы оркестратор не убивал его SIGKILL посреди запроса.

Когда использовать worker_threads, cluster, child_process, а когда просто больше инстансов?

Что должно быть в сильном ответе:worker_threads выполняют JavaScript параллельно в одном процессе с возможностью общей памяти (SharedArrayBuffer, transferable-объекты) и подходят для CPU-задач вроде обработки изображений или парсинга, обычно через пул. cluster форкает процессы с общим портом, чтобы задействовать все ядра, но в контейнерах проще один процесс на контейнер и горизонтальное масштабирование. child_process нужен для запуска внешних программ или изоляции рискованной работы. Выбор зависит от того, что узкое место: CPU, изоляция или пропускная способность.

p99 задержки вашего Node.js API в продакшене резко выросла, а CPU в норме. Как будете разбираться?

Что должно быть в сильном ответе:Сначала посмотрю на задержку event loop и паузы GC, потом на внешние вызовы через distributed tracing: не замедлились ли БД, кэш или сторонний API. Другие частые причины: исчерпанный пул соединений, забитый пул потоков libuv (по умолчанию 4) из-за fs, dns.lookup или crypto и отсутствие таймаутов, из-за чего запросы стоят в очереди за медленными. Сопоставлю с последними деплоями и трафиком, воспроизведу под нагрузкой и подтвержу фикс метриками.

Какая у вас стратегия по unhandledRejection и uncaughtException в продакшене?

Что должно быть в сильном ответе:После необработанного исключения состояние процесса неизвестно, поэтому безопасно залогировать ошибку с контекстом, сбросить логи и метрики и выйти с ненулевым кодом, чтобы супервизор перезапустил процесс. Попытка работать дальше грозит испорченным состоянием и утечкой ресурсов. Unhandled rejection в современном Node и так роняет процесс, а настоящее решение в том, чтобы их не допускать: корректные await, централизованная обработка ошибок и линт-правила вроде no-floating-promises.

Как пробросить контекст запроса, например trace ID, через все async-вызовы без ручной передачи?

Что должно быть в сильном ответе:Через AsyncLocalStorage из node:async_hooks: в middleware запускаете хранилище на каждый запрос через als.run(), и любой код в этой async-цепочке может его прочитать, например логгер. На этом построены request-scoped логирование и трейсинг в OpenTelemetry и фреймворках вроде NestJS. Хранилище стоит держать маленьким, не превращать в скрытый DI и помнить, что контекст может теряться в некоторых библиотеках на собственных колбэках.

Как защитить Node.js API и его зависимости?

Что должно быть в сильном ответе:На уровне кода: валидация ввода схемами, параметризованные запросы, защита от prototype pollution при слиянии пользовательских объектов, security-заголовки, rate limiting и нормальная аутентификация. Для supply chain: коммитить lock-файл, ставить через npm ci, гонять npm audit или сканер в CI, минимизировать зависимости и осторожно относиться к install-скриптам. В рантайме: запуск не от root, секреты вне кода и логов, поддерживаемая LTS-версия и при необходимости permission model Node, чтобы ограничить доступ к fs или дочерним процессам.