Перейти к основному содержимому

Node.js

Экспресс-шпаргалка 20/20​

  1. Event Loop проходит фазы timers -> pending callbacks -> poll -> check -> close, а microtasks (Promise, nextTick) выполняются между фазами.
  2. Streams выбирают для больших payload и непрерывных данных, чтобы не держать все в памяти и использовать backpressure.
  3. Buffer нужен для бинарных данных: файлы, сокеты, криптография, кодировки.
  4. nextTick выполняется раньше всего, setImmediate в check, setTimeout в timers после минимальной задержки.
  5. worker_threads для CPU-bound задач, cluster для масштабирования HTTP-процесса по ядрам.
  6. CommonJS (require) проще для legacy, ESM (import) стандартнее и лучше для современного tooling.
  7. Централизованный error handling: единый error schema, middleware/filters, correlation id и разделение 4xx/5xx.
  8. Graceful shutdown: stop accepting new requests -> drain active -> close DB/broker -> forced exit by timeout.
  9. От перегрузки защищают rate limit, очереди, таймауты, circuit breaker и ограничение параллелизма.
  10. Логи должны быть структурными (JSON), с traceId/requestId, уровнями и метриками latency/error-rate.
  11. Конфиг: 12-factor, fail-fast валидация env при старте, секреты только через secret manager.
  12. Большие файлы обрабатывают stream/pipeline с лимитами размера, type-check и защитой от медленных клиентов.
  13. health показывает жив ли процесс, readiness готов ли сервис принимать трафик с учетом зависимостей.
  14. JWT безопасен только с проверкой alg, подписи, exp/aud/iss, ротацией ключей и коротким TTL access-токена.
  15. Кэш ставят на read-heavy пути с TTL, стратегией инвалидации и защитой от cache stampede.
  16. WebSocket требует heartbeat/ping-pong, лимитов соединений, backpressure и стратегии reconnect.
  17. Утечки памяти ищут через heap snapshots, allocation profiling и сравнение роста heap во времени.
  18. ORM ускоряет CRUD, query builder/raw SQL нужен для сложных и критичных по perf запросов.
  19. N+1 лечат batching, joins/eager loading и измерением количества запросов на один API call.
  20. Backward compatibility достигают additive changes, versioning, deprecation window и контрактными тестами.

1. Как устроен Event Loop в Node.js и его фазы?​

Теги: nodejs, backend, event-loop, async Сложность: Middle/Senior

Короткий ответ​

Node Event Loop обрабатывает callback-очереди по фазам: timers -> pending callbacks -> poll -> check -> close callbacks, а microtasks выполняются между фазами.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: CPU-bound операции в request path блокируют Event Loop и увеличивают latency для всех пользователей.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

console.log('A');
setTimeout(() => console.log('timer'), 0);
setImmediate(() => console.log('immediate'));
process.nextTick(() => console.log('nextTick'));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как устроен Event Loop в Node.js и его фазы?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

2. Когда использовать Streams вместо чтения файла целиком?​

Теги: nodejs, backend, streams Сложность: Middle/Senior

Короткий ответ​

Streams применяют для больших или непрерывных данных, чтобы читать/писать чанками и не держать весь payload в памяти.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Неправильная обработка backpressure приводит к росту памяти и нестабильности процесса.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

import { createReadStream } from 'node:fs';
createReadStream('./big.log').pipe(process.stdout);

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда использовать Streams вместо чтения файла целиком?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Запускают изменения без наблюдаемости и runbook.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Как поведение изменится под пиковым трафиком?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

3. Что такое Buffer и где он нужен?​

Теги: nodejs, backend, buffer Сложность: Middle/Senior

Короткий ответ​

Buffer - бинарный контейнер памяти в Node для работы с байтами, сетевыми пакетами и файлами.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

const payload = Buffer.from('hello', 'utf8');
console.log(payload.toString('hex'));

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое Buffer и где он нужен?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Держат тяжелую обработку в синхронном request path.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

4. Разница между process.nextTick, setImmediate и setTimeout?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

process.nextTick выполняется раньше очереди фаз, setImmediate - в check phase, setTimeout - в timers phase после минимального delay.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Разница между process.nextTick, setImmediate и setTimeout?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

5. Когда выбирать worker_threads, а когда cluster?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

worker_threads - для CPU-bound задач внутри одного процесса, cluster - для масштабирования HTTP процесса по ядрам через форки.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда выбирать worker_threads, а когда cluster?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие метрики покажут деградацию раньше инцидента?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

6. Разница CommonJS и ESM в Node.js?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

CommonJS (require) загружается синхронно и исторически основной в Node, ESM (import) стандартизирован и лучше для tree-shaking/interop с современным tooling.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

// CommonJS
const legacy = require('./lib.cjs');
// ESM
import modern from './lib.mjs';

Углубление (2-3 минуты)​

  1. Свяжите тему "Разница CommonJS и ESM в Node.js?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Разберите поведение системы под пиковым трафиком и деградацией внешних зависимостей.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

7. Как организовать централизованный error handling в Node API?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Единый error handling строят через централизованный middleware, стандартный формат ошибки и логирование с correlation id.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать централизованный error handling в Node API?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите границы request path и вынос тяжелых операций в фон.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

8. Как реализовать graceful shutdown сервиса?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Graceful shutdown: перестать принимать новые запросы, дождаться активных операций, закрыть соединения и завершить процесс по таймауту.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

process.on('SIGTERM', async () => {
  await server.close();
  process.exit(0);
});

Углубление (2-3 минуты)​

  1. Свяжите тему "Как реализовать graceful shutdown сервиса?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите границы request path и вынос тяжелых операций в фон.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

9. Как защитить API от перегрузки (rate limit/backpressure)?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Защита от перегрузки включает rate limit, backpressure, очереди, таймауты и деградационный fallback.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как защитить API от перегрузки (rate limit/backpressure)?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

10. Как проектировать структуру логирования и трассировки?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Структура логирования: уровни (info/warn/error), request-id/trace-id, контекст запроса и машинно-читаемый JSON формат.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как проектировать структуру логирования и трассировки?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Как поведение изменится под пиковым трафиком?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

11. Как выстроить конфигурацию окружений и работу с secrets?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Конфиги держат в env + schema validation на старте, секреты - в secret manager, а не в репозитории.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как выстроить конфигурацию окружений и работу с secrets?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие метрики покажут деградацию раньше инцидента?
  2. Как поведение изменится под пиковым трафиком?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Health/readiness и корреляцию логов/метрик.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

12. Как обрабатывать загрузку больших файлов в Node?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Большие файлы обрабатывают потоками и пайплайном, чтобы избежать OOM и блокировки Event Loop.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как обрабатывать загрузку больших файлов в Node?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие метрики покажут деградацию раньше инцидента?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

13. Зачем и как добавлять healthcheck/readiness endpoints?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Healthcheck отвечает жив ли процесс, readiness - готов ли сервис принимать трафик с учетом зависимостей.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

app.get('/health', (_req, res) => res.status(200).json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Зачем и как добавлять healthcheck/readiness endpoints?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Держат тяжелую обработку в синхронном request path.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

14. Как безопасно работать с JWT на backend?​

Теги: nodejs, backend, security, auth Сложность: Middle/Senior

Короткий ответ​

JWT на backend требует проверки подписи/exp/aud/iss, ротации ключей и продуманной стратегии refresh/revoke.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Ошибки в валидации токенов и сроков жизни приводят к уязвимостям и неуправляемым 401.
  3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как безопасно работать с JWT на backend?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите границы request path и вынос тяжелых операций в фон.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Как поведение изменится под пиковым трафиком?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

15. Как организовать кэширование на стороне Node-сервиса?​

Теги: nodejs, backend, cache Сложность: Middle/Senior

Короткий ответ​

Кэширование ускоряет hot-path чтения, но требует TTL, invalidation и защиты от stampede.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Без стратегии инвалидации кэш становится источником stale-данных и трудноуловимых багов.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать кэширование на стороне Node-сервиса?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите границы request path и вынос тяжелых операций в фон.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

16. Как реализовать WebSocket и какие у него риски?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

WebSocket дает двунаправленный канал в реальном времени, но требует heartbeat, контроль количества соединений и backpressure.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как реализовать WebSocket и какие у него риски?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Разберите поведение системы под пиковым трафиком и деградацией внешних зависимостей.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

17. Как отлавливать утечки памяти в Node приложении?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Утечки памяти ловят через heap snapshots, allocation profiling и анализ роста heap на длительном интервале.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Как отлавливать утечки памяти в Node приложении?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  2. Держат тяжелую обработку в синхронном request path.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что вынесете в фон, чтобы не блокировать critical path?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Runbook деградации внешней зависимости.
  2. Health/readiness и корреляцию логов/метрик.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

18. Когда выбирать ORM, а когда query builder?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

ORM удобно для CRUD и скорости разработки, query builder/raw SQL - для сложных/критичных по производительности запросов.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда выбирать ORM, а когда query builder?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Разберите поведение системы под пиковым трафиком и деградацией внешних зависимостей.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Запускают изменения без наблюдаемости и runbook.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Health/readiness и корреляцию логов/метрик.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

19. Что такое N+1 на backend и как его уменьшать?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

N+1 - это серия мелких запросов вместо батча; обычно лечится eager loading, joins и batching.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое N+1 на backend и как его уменьшать?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, какие сигналы observability подтверждают устойчивость решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Запускают изменения без наблюдаемости и runbook.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как поведение изменится под пиковым трафиком?
  2. Какие метрики покажут деградацию раньше инцидента?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Health/readiness и корреляцию логов/метрик.
  2. Границы Event Loop/I-O/CPU и backpressure.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js

20. Как обеспечивать backward compatibility API?​

Теги: nodejs, backend Сложность: Middle/Senior

Короткий ответ​

Backward compatibility API обеспечивают через versioning, additive changes, deprecation period и контрактные тесты.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для API-сервисов, фоновых обработчиков, BFF и интеграций с внешними системами.
  2. Главный риск: Отсутствие лимитов, таймаутов и наблюдаемости в Node-сервисе ведет к каскадным инцидентам под нагрузкой.
  3. Как проверяете решение: Сверяю поведение по runbook: детектирование, mitigation и проверка восстановления после сбоя.

Мини-пример​

import express from 'express';
const app = express();
app.get('/ping', (_req, res) => res.json({ ok: true }));

Куда дальше​

  1. Вернитесь в модуль: Node.js.
  2. Сверьтесь с картой темы: Node.js.
  3. Продолжайте по маршруту: Middle трек.
  4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)​

  1. Свяжите тему "Как обеспечивать backward compatibility API?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Разберите поведение системы под пиковым трафиком и деградацией внешних зависимостей.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Держат тяжелую обработку в синхронном request path.
  2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие метрики покажут деградацию раньше инцидента?
  2. Что вынесете в фон, чтобы не блокировать critical path?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы Event Loop/I-O/CPU и backpressure.
  2. Runbook деградации внешней зависимости.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Node.js
  2. Обучение: Web и сеть
  3. Карта подготовки: Node.js