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

Node.js

Для чего модуль​

Освоить Node.js как серверную платформу, а не только как «среду запуска JS»: понимать runtime, проектировать устойчивые API и сопровождать сервис в production.

Результат после прохождения​

  1. Вы объясняете Event Loop и поведение асинхронности в Node без путаницы.
  2. Вы проектируете API-слой с контрактом ошибок, таймаутами и защитой от деградации.
  3. Вы понимаете, как работать с памятью, логированием, health-check и graceful shutdown.
  4. Вы умеете разбирать инциденты через метрики, логи и воспроизводимый runbook.

Термины и аббревиатуры​

ТерминКоротко
Event LoopЦикл обработки задач
BackpressureКонтроль скорости потока
IdempotencyБезопасный повтор операции
ReadinessГотовность принимать трафик
p95/p99Хвостовые метрики задержки

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Каждый урок связывайте с одним сервисом (реальным или учебным): API + DB + внешняя зависимость.
  2. Любое решение формулируйте через SLA/SLO и риск-профиль.
  3. После урока добавляйте минимум один технический артефакт: код, runbook, checklist.

Программа модуля​

Урок 1. Runtime и async​

Цель: понимать, как Node обрабатывает нагрузку и почему «иногда тормозит».

Event Loop и очередь задач​

Ключевые элементы:

  1. Phases Event Loop (timers, poll, check и т.д.).
  2. Microtasks queue (Promise callbacks).
  3. process.nextTick и риск starvation.

I/O-bound vs CPU-bound​

Node отлично работает с I/O, но CPU-heavy вычисления могут блокировать loop.

// Плохо: тяжелая синхронная работа в request path
app.get('/report', (req, res) => {
  const data = buildHugeReportSync();
  res.json(data);
});

Streams и backpressure​

Для больших данных используйте stream pipeline, чтобы не раздувать память.

import { pipeline } from 'node:stream/promises';

await pipeline(readable, transform, writable);

Где ломается в проде​

  1. Блокирующие операции в hot-path endpoint.
  2. Чтение больших файлов/ответов «целиком в память».
  3. Непонимание разницы nextTick/setImmediate/setTimeout.

Мини-задача (обязательная)​

Сравните два варианта обработки большого файла: readFile и stream pipeline. Зафиксируйте разницу по памяти и latency.

Что спросит интервьюер: почему setImmediate, setTimeout и process.nextTick ведут себя по-разному.

Критерий готовности по уроку: вы можете по симптомам определить, упирается ли сервис в CPU, I/O или архитектурный bottleneck.

Урок 2. Сервисная архитектура API​

Цель: построить API-слой, который предсказуем в ошибках и удобен в эксплуатации.

Структура и границы​

  1. Route/controller слой.
  2. Service/use-case слой.
  3. Infra layer (DB, внешние API, cache, queue).

Принцип: бизнес-правила не смешиваются с transport/infra кодом.

Error contract​

Стабильный контракт снижает время диагностики и улучшает UX.

{
  "error": {
    "code": "ORDER_CONFLICT",
    "message": "Order already confirmed",
    "traceId": "f1f5..."
  }
}

Таймауты, retry, idempotency​

  1. Таймаут обязателен на внешние вызовы.
  2. Retry только для транзиентных ошибок и с backoff.
  3. Для критичных операций используйте idempotency key.

Где ломается в проде​

  1. API возвращает хаотичные форматы ошибок.
  2. Retry без лимита усиливает деградацию.
  3. Секреты и конфиги «зашиты» в код/образ.

Мини-задача (обязательная)​

Опишите контракт ошибок для 5 типовых сценариев: валидация, auth, conflict, external timeout, unknown error.

Что спросит интервьюер: как вы отделяете бизнес-ошибки от инфраструктурных.

Критерий готовности по уроку: вы можете показать API-контур, в котором ошибки и таймауты контролируются, а не «случайны».

Урок 3. Надежность под нагрузкой​

Цель: проектировать сервис так, чтобы он деградировал контролируемо, а не падал каскадно.

Protection patterns​

  1. Rate limiting и throttling.
  2. Queue/buffer для всплесков нагрузки.
  3. Circuit breaker и bulkhead-подход.

Worker threads и cluster​

  1. worker_threads — для CPU-bound задач.
  2. cluster/multi-process — масштабирование по ядрам и отказоустойчивость процесса.

Cache и consistency trade-offs​

  1. Кэш снижает latency, но может отдавать stale данные.
  2. Нужна стратегия invalidation и fallback на cache miss.
  3. Hot key и cache stampede должны быть предусмотрены.

Где ломается в проде​

  1. Нет лимитов на дорогие endpoint.
  2. Очередь не ограничена и становится «черной дырой».
  3. Нет плана деградации при отказе внешнего сервиса.

Мини-задача (обязательная)​

Подготовьте план защиты endpoint при росте трафика x10: лимиты, деградация ответа, очереди, алерты, rollback критерии.

Что спросит интервьюер: что вы будете делать первым делом при росте p95 latency.

Критерий готовности по уроку: вы можете описать надежностный контур сервиса и объяснить, как он ведет себя при отказах.

Урок 4. Эксплуатация​

Цель: сопровождать Node-сервис в проде как инженерную систему.

Наблюдаемость​

  1. Structured logs (JSON) с traceId/requestId.
  2. Метрики: latency, error rate, saturation.
  3. Health/readiness probes.

Память и диагностика​

  1. Разница между heap leak и внешним ростом памяти.
  2. Heap snapshots и профилирование.
  3. Корреляция роста памяти с конкретными сценариями нагрузки.

Graceful shutdown и релизы​

  1. Перестать принимать новый трафик.
  2. Дождаться завершения in-flight запросов.
  3. Закрыть соединения к DB/queue/cache.

Где ломается в проде​

  1. Rollout без readiness checks.
  2. Логи без корреляции, невозможно собрать таймлайн инцидента.
  3. При рестарте теряются in-flight операции.

Мини-задача (обязательная)​

Соберите post-release checklist и incident runbook: что проверяем в первые 30 минут после релиза и при каких условиях откатываемся.

Что спросит интервьюер: как вы расследуете утечку памяти в живом сервисе.

Критерий готовности по уроку: вы можете провести расследование инцидента от симптома до root cause и описать превентивные меры.

Практика​

  1. Пройдите Node.js вопросы.
  2. Реализуйте API endpoint с timeout, retry guard, idempotency и единым error contract.
  3. Добавьте health, readiness, structured logging и correlation id.
  4. Смоделируйте нагрузку и зафиксируйте поведение p95/p99 до и после оптимизаций.
  5. Подготовьте инцидентный runbook для кейса «рост latency + рост ошибок внешнего API».
  6. Смоделируйте деградацию внешнего API в Песочнице и прогоните runbook восстановления.

Связь с треками и вопросами​

  1. Треки: Middle трек, Senior трек.
  2. Вопросы: Node.js, NestJS, Базы данных.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности​

Вы объясняете Node-сервис как production-систему: архитектура, защита от деградации, эксплуатация, инцидентная диагностика.

Артефакты после модуля​

  1. Runbook деградации API (симптомы, проверка, действия).
  2. Шаблон error contract и policy таймаутов/retry.
  3. Release checklist + rollback критерии.
  4. Набор из 6 сильных interview-ответов по Node.js.

Куда дальше​

  1. NestJS
  2. Базы данных
  3. Node.js