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