Вопросы на собеседовании: Node.js-разработчик

Я бы сохранил единый deployment, но сделал каждый модуль отдельно контролируемой границей владения в коде и доступе к данным.

• Order, Inventory и Billing открывали бы узкие TypeScript entry points, а package exports, project references и правила dependency-cruiser или ESLint запрещали бы импорт внутренних файлов.
• Каждый модуль владел бы своими таблицами PostgreSQL и repository; другой модуль вызывает публичный API вместо одной из 7 прямых записей или join по закрытым таблицам в коде приложения.
• CI ломался бы на любом из 18 запрещённых рёбер зависимостей, запускал contract tests публичных entry points и публиковал граф зависимостей, чтобы размывание границ было видно до merge.
• Межмодульная работа, которой нужна одна транзакция базы, шла бы через явный application coordinator и API модулей, а некритичные побочные эффекты через типизированные in-process events с назначенными владельцами.

Я дам Order и Inventory раздельное владение и заменю общую транзакцию явным процессом резервирования товара.

• Order владеет состоянием и суммой заказа, а Inventory единолично владеет доступным количеством и резервом с ID заказа и сроком жизни 10 минут.
• Checkout создаёт заказ в статусе Pending, отправляет ReserveStock с ID заказа и подтверждает его только после долговечного резерва от Inventory, поэтому ни один сервис не пишет в таблицы другого контекста.
• Отклонённый или истёкший резерв отменяет Pending-заказ, а повторные команды резерва и освобождения используют тот же ID заказа и ограничение уникальности.
• Если бизнес требует создать заказ и уменьшить остаток за 1 атомарный шаг без статуса Pending, я оставлю этот инвариант в 1 контексте вместо внедрения 2PC.

Я оставлю синхронными решения, нужные для ответа покупателю, а работу после подтверждения опубликую в Kafka.

• Браузер использует HTTP JSON, а внутренние pricing, inventory и payment могут использовать gRPC, если уже есть сгенерированные Protobuf-контракты; одна смена протокола не исправит плохой бюджет задержки.
• Я выделю около 50 мс на edge и приложение, 80 мс на pricing, 120 мс на inventory, 180 мс на payment и сохраню 70 мс на сетевой разброс и сериализацию.
• После коммита заказа transactional outbox публикует OrderConfirmed в Kafka в пределах 1 секунды для доставки, письма и аналитики, которые не должны расходовать бюджет ответа в 500 мс.
• Если payment не укладывается в свои 180 мс, я верну результат Pending и закончу процесс асинхронно вместо синхронной цепочки, регулярно превышающей 500 мс.

Я оставлю единые пограничные контроли в gateway, а авторизацию на уровне ресурса выполню в сервисе, владеющем заказом.

• Gateway завершает TLS, проверяет подпись JWT по кешированному JWKS, маршрутизирует запросы, ограничивает body значением 2 МБ, применяет лимиты по клиенту и пишет низкокардинальные метрики трафика.
• При 100 000 RPS реплики gateway должны быть stateless и не обращаться к базе пользователей или политик на каждый запрос; кешированные ключи и локальная проверка токена сохраняют масштабируемость edge-слоя.
• Gateway может потребовать scope orders:read, но Order-сервис по актуальным доменным данным проверяет, владеет ли пользователь заказом 8472 или имеет tenant-specific право поддержки.
• Я не помещу в gateway оркестрацию checkout, переходы состояния заказа или специфичное для сервиса преобразование ответа, потому что уже 3 такие функции создадут связанное узкое место деплоя.

Я бы использовал Kubernetes для discovery и балансировал на уровне gRPC streams, а не по числу TCP connections.

• Service вместе с EndpointSlices или xDS открывает 40 готовых pods, а клиенты держат несколько HTTP/2 channels и применяют round robin по разрешённым endpoints вместо одного закреплённого через DNS канала.
• L7 gRPC proxy должен выбирать upstream по активным requests или streams, а не по наименьшему числу TCP connections, потому что одно соединение может нести тысячи из 80 000 одновременных streams.
• Readiness исключает pod из нового выбора endpoints, но не запрещает новые streams в уже открытом channel; drain также должен вызвать server.tryShutdown в grpc-js или отправить GOAWAY и отклонить новые вызовы.
• Я бы дал 60 секунд на кооперативное завершение streams, затем выполнил force shutdown, а максимальный возраст соединения с jitter постепенно обновлял распределение channels без синхронного переподключения всех клиентов.

Я использую оркестрируемую сагу с долговечным состоянием, потому что 4 упорядоченным шагам и их компенсациям нужна одна видимая запись процесса.

• Оркестратор сохраняет ID checkout, текущий шаг, число попыток и дедлайн 15 минут, затем отправляет каждую команду через outbox после коммита своей локальной транзакции.
• При сбое он компенсирует в обратном порядке: отменяет доставку, аннулирует авторизацию платежа, освобождает товар и переводит заказ в Cancelled.
• Каждая прямая и компенсирующая команда использует ключ вроде checkout-482:reserve-stock, а сервис атомарно записывает его со своим локальным изменением до подтверждения.
• При таймауте временный сбой повторяется не более 3 раз, после чего сага переходит в ManualReview, если компенсацию вроде аннулирования платежа подтвердить не удалось.

Я проведу единую стабильную идентичность операции через все 3 сервиса и дам каждому побочному эффекту свой детерминированный дочерний ключ.

• Checkout до начала работы сохраняет tenant ID, endpoint, ключ идемпотентности, SHA-256 fingerprint запроса, состояние и ответ под ограничением уникальности.
• Он выводит отдельные ключи вроде key-731:payment и key-731:shipment, поэтому все 4 повтора приходят в те же downstream-операции, не смешивая 2 разных эффекта.
• Каждый сервис захватывает свой ключ и применяет бизнес-изменение в 1 локальной транзакции; конкурентный дубликат получает сохранённый результат или ответ 202 Pending.
• Я храню ключи 7 дней, дольше окон HTTP-ретраев и повторного чтения сообщений, а тот же ключ с другим fingerprint отклоняю как конфликт 409.

Я сначала расширю provider, независимо переведу 12 потребителей и сожму контракт только после доказанного телеметрией отказа от старого поля.

• На 1-й неделе provider принимает customerName или новое структурированное поле customer, возвращает оба представления и нормализует их в 1 доменную модель на границе API.
• Consumer-driven contract tests проверяют обе формы в CI, а каждый запрос записывает ID потребителя и версию контракта, чтобы незарегистрированный клиент не исчез из подсчёта миграции.
• Я буду переводить примерно по 2 потребителя в неделю без синхронного релиза, опубликую сгенерированный клиент для новой формы и сохраню совместимость expanded-provider с откатом.
• После миграции всех 12 потребителей и 0 обращений к старому полю в течение 14 дней я перестану его возвращать, а приём и adapter-код удалю в следующем релизе.

Я помещу всю политику устойчивости внутрь 600 мс, а не дам каждой попытке независимый таймаут.

• Я зарезервирую 100 мс на работу приложения, 120 мс на базу, 80 мс на разброс ответа и отдам зависимости не более 300 мс суммарно.
• При измеренном p99 зависимости около 90 мс я начну с таймаута попытки 140 мс и разрешу 1 повтор после jitter до 20 мс только для идемпотентных вызовов и временных ошибок.
• Переданный дальше дедлайн отменяет downstream-работу, а повтор не начинается, если осталось меньше 160 мс, поэтому истёкший запрос не создаёт бесполезную фоновую нагрузку.
• Я начну с размыкания breaker при 50% подходящих ошибок минимум в 20 вызовах, открою его на 5 секунд, разрешу 2 half-open проверки и настрою числа по трафику, а не догадкам.

Я изолирую ёмкость рекомендаций от основного пути товара и уберу рекомендации до того, как они исчерпают 60 соединений базы.

• Основные чтения товара сохраняют пул PostgreSQL на 60 соединений, а рекомендации получают отдельный HTTP agent на 20 sockets, лимит конкурентности 40 и ограниченную очередь на 80 запросов.
• Опциональный вызов получает таймаут 80 мс без ретрая внутри запроса; при сбое API возвращает товар с recommendationStatus unavailable или значение Redis не старше 5 минут.
• После заполнения 80 мест опциональной очереди новые рекомендации сразу пропускаются, поэтому 12 000 RPS не превращают медленную зависимость в неограниченные promises и рост heap.
• Я отдельно построю графики основной latency, пропущенных рекомендаций, глубины очереди, использования sockets и возраста stale-кеша, затем под нагрузкой проверю, что сбой рекомендаций не поднимает p95 товара выше 250 мс.

Я запущу 18 одноядерных процессов-реплик, по шесть на каждом из трёх 8-ядерных хостов; при 24 000 RPS каждая обычно обслуживает около 1 333 RPS, а после потери хоста нагрузка вырастает до 2 000 RPS.

• Один JavaScript event loop использует одно ядро для кода приложения, поэтому остальные ядра задействуют дополнительные процессы, а не увеличение одного процесса.
• Цель в 2 000 RPS составляет 67% от измеренного предела в 3 000 RPS и оставляет запас для event loop и всплесков трафика.
• После потери одного хоста останутся 12 реплик и ровно 24 000 RPS плановой ёмкости, а два свободных ядра на хосте останутся ОС и нативной работе.
• Я вынесу состояние наружу и проведу нагрузочный тест базы, кеша, пулов соединений и сети на 36 000 RPS, потому что ёмкость процессов не равна сквозной ёмкости.

Обычно я выберу 24 pod с одним процессом и запросом 1 vCPU вместо четырёх cluster workers внутри каждого из шести pod.

• Kubernetes сможет независимо размещать, проверять, перезапускать и дренировать каждый процесс, а не считать четыре границы памяти и отказа одним pod.
• CPU, RSS, задержка event loop и readiness одного pod тогда описывают один процесс Node.js, поэтому лимиты и сигналы автоскейлинга проще интерпретировать.
• Rolling update может заменять несколько из 24 процессов за раз, тогда как замена одного pod с cluster одновременно убирает четыре процесса.
• Я оставлю cluster для отдельной 4-ядерной VM или платформы без оркестрации процессов и задокументирую исключение, если sidecar или другие ресурсы каждого pod необычно дороги.

Для WebSocket upgrade я выберу взвешенный least-connections, а для короткого HTTP-трафика least-outstanding-requests или round robin.

• Least-connections направляет новый upgrade на реплику с меньшим числом открытых сокетов и удерживает ожидаемые 5 000 соединений на реплику ниже измеренного лимита в 6 000.
• Я не позволю 20 000 долгим соединениям определять выбор для HTTP, поэтому балансировщику нужны отдельные счётчики или backend pools для upgrade и обычных запросов.
• Веса позволяют сократить трафик на меньшую или прогревающуюся реплику, а consistent hashing не нужен без явного требования к локальности после выноса состояния.
• Readiness должна запретить новые upgrade до дренирования реплики, а существующие сокеты остаются на ней до закрытия или ограниченного дедлайна деплоя.

Я не буду использовать sticky routing для HTTP, вынесу сессии и сообщения наружу и оставлю привязку только для WebSocket на время открытого соединения.

• Непрозрачный session ID может ссылаться на состояние в Redis с TTL 30 минут, поэтому любой из шести экземпляров сможет аутентифицировать следующий HTTP-запрос.
• Общий реестр соединений и разделённый pub-sub направят сообщение на реплику с нужным сокетом при среднем значении 10 000 сокетов на реплику.
• Привязка по cookie или исходному IP может скрыть состояние в памяти, но создаёт перекос нагрузки и теряет непрерывность при замене выбранного pod во время rollout.
• Клиенты должны переподключаться с jitter и resume cursor, чтобы безопасно перенести соединение без сохранения памяти старого процесса.

Оставшиеся 25 мс я разделю на 10 мс ожидания event loop, 10 мс работы приложения и 5 мс запаса, ограничив любую непрерывную синхронную часть 5 мс.

• При 400 RPS синхронная работа по 1,5 мс требует около 600 мс одного ядра в секунду, поэтому процесс начинает примерно с 60% event-loop utilization без учёта callbacks и GC.
• Я буду записывать monitorEventLoopDelay как гистограмму и потребую, чтобы её p99 оставался ниже выделенных 10 мс под реальной смесью запросов.
• Я сравню снимки eventLoopUtilization по окнам нагрузки и буду исследовать устойчивые значения выше примерно 70%, а не считать одно накопленное значение метрикой запроса.
• CPU profiles найдут части дольше 5 мс, которые я ограничу, разобью планируемыми уступками event loop или перенесу в worker pool перед повторной проверкой p99 в 120 мс.

Я запущу шесть worker threads на pod, не менее двух реплик и буду передавать владение каждым ArrayBuffer размером 8 MiB вместо клонирования.

• Шесть workers дают теоретические 150 задач в секунду, а цель загрузки 70% даёт около 105 задач в секунду и оставляет CPU основному event loop и нативной работе.
• Две реплики дают около 210 задач в секунду на целевой загрузке, а ограниченная входная очередь должна отклонять или откладывать работу сверх этого темпа.
• Transfer перемещает backing store ArrayBuffer и отсоединяет его у отправителя, тогда как clone для 200 входов в секунду копировал бы около 1,6 GiB в секунду ещё до ответов.
• Если отправителю нужны исходные байты, я сделаю копирование явным или спроектирую синхронизированный протокол SharedArrayBuffer, затем вместе измерю вычисления, обмен сообщениями, RSS и p99.

Я начну с UV_THREADPOOL_SIZE=4, ограничу получение ключей тремя конкурентными операциями на реплику и проведу бенчмарк до увеличения пула.

• Криптографическая нагрузка потребляет около 2,4 ядро-секунды в секунду на реплику, поэтому большой пул не создаст дополнительный CPU при лимите 4 vCPU.
• Три конкурентные операции по 40 мс дают теоретические 75 в секунду и оставляют один слот пула для файловой системы, dns.lookup, zlib и другой общей работы libuv.
• Размер 4 создаёт 48 потоков libuv на 12 репликах, тогда как значение 16 создаст 192 потока и может добавить переключения контекста и память без полезного throughput.
• Я сравню размеры 4, 6 и 8 по времени в очереди crypto, p99 файловой системы, CPU и RSS и вынесу работу с паролями в отдельные реплики, если общий пул всё ещё нарушает любой SLO.

Цепочка microtasks не даёт выполняться фазам timers и I/O, потому что Node.js продолжает опустошать очередь microtasks до перехода event loop дальше.

• Promise.then и queueMicrotask планируют новые microtasks, поэтому замена рекурсии одним из этих API не уступает event loop; рекурсивный process.nextTick ещё агрессивнее, поскольку его очередь выполняется раньше обычных promise microtasks.
• Я бы обрабатывал измеренную часть, например 500 элементов, сохранял cursor и ждал setImmediate из node:timers/promises перед следующей частью, чтобы timers и poll callbacks получили время.
• Если 100 000 шагов выполняют тяжёлые CPU-вычисления, а не короткую координацию, я бы отправил batch в ограниченный пул worker_threads вместо создания ещё более длинной последовательности проходов event loop.
• Нагрузочный тест отслеживал бы p99 monitorEventLoopDelay, eventLoopUtilization, опоздание timers, throughput и глубину очереди и сохранял размер части только при выполнении бюджета таймера 10 мс.

Я начну с --max-old-space-size=1024, буду считать полный лимит 2 GiB бюджетом реплики, размещу не более шести таких pod на узле 16 GiB и сниму heap snapshots только на изолированной диагностической реплике.

• Для ёмкости важен RSS, потому что он включает heap V8, Buffers, нативные аллокации, код и стеки потоков; измеренный пик 1,6 GiB оставляет лишь около 400 MiB до лимита pod.
• Шесть лимитов по 2 GiB резервируют 12 GiB и оставляют 4 GiB операционной системе, Kubernetes, служебным процессам и временному давлению на узел.
• Snapshot может остановить event loop и потребовать много дополнительной памяти, поэтому я выведу реплику из трафика и дам диагностическому pod не менее 3 GiB вместо риска OOM в продакшн-pod на 2 GiB.
• Я сравню прогретые post-GC snapshots по retained size и retaining path, затем проверю исправление по наклону RSS, времени GC и soak test, а не только увеличу heap limit.

Я бы позволил балансировщику первым закрывать idle connections, отдельно ограничил медленную загрузку запроса и обеспечил 2-секундный бюджет handler через отмену.

• Я бы задал server.keepAliveTimeout около 55 секунд, чтобы балансировщик, владеющий и повторно использующий клиентскую сторону upstream-соединения, закрывал его на 50-й секунде раньше server-side idle timeout Node.js.
• Я бы начал с headersTimeout 10 секунд и requestTimeout 20 секунд на полный запрос до 2 МиБ, добавив лимиты числа headers и размера body, чтобы медленные клиенты не занимали parsers бесконечно.
• Route использовал бы AbortController с дедлайном меньше 2 секунд и передавал signal в fetch, получение соединения базы и потоковую работу, потому что socket timeouts сервера не отменяют promises приложения автоматически.
• Я бы согласовал настройки client agent и proxy в нагрузочном тесте и отслеживал connection resets, ответы 408, активные sockets, reuse rate и p99 до изменения значений 55, 10 или 20 секунд.