Гео-аналитическая платформа вдвоём за 2,5 месяца: история spec-driven разработки

Автор поделился опытом старта проекта с чистого листа. Перед ним стояла амбициозная задача, не было легаси и была полная свобода выбора подхода. Он решил максимально довериться AI и больше не трогать код. Изначально были сомнения, что такой подход выдержит реальный масштаб, так как опыт подсказывал, что чем больше проект, тем быстрее AI путается в контексте и упирается в лимиты.

Через 2,5 месяца работы вдвоём удалось запустить гео-аналитическую платформу. Автор отмечает, что в до-AI эпоху такой проект строили бы годами. Этот опыт изменил его представление о разработке.

Читать далее

⁣Грейсфул шатдаун: как SIGTERM и postMessage ломают порядок сигналов

Каждый middle/senior разработчик Node.js сталкивался с грейсфул шатдауном, но редкий замечает скрытую ловушку — смешивание process.on('SIGTERM') и Worker.prototype.postMessage. Из-за разницы приоритетов событий и микрозадач теряются данные в production.

Проблема приоритетов событий
SIGTERM — системное событие с высоким приоритетом в цикле событий. postMessage — асинхронная операция, попадающая в очередь микрозадач. Если SIGTERM приходит до завершения отправки сообщения, оно обрабатывается уже после shutdown. Результат — потеря данных, которые должны были уйти в Worker.

Production-пример и диагностика
Рассмотрим типичный код:

process.on('SIGTERM', () => {
  console.log('Shutdown');
  worker.terminate();
});
worker.postMessage({ type: 'data', payload: result });

Здесь postMessage может быть прерван сигналом. Как диагностировать:
* Логируйте порядок событий с таймстемпами.
* Используйте process.on('SIGTERM', { once: true }) для однократного вызова.
* Проверяйте флаг isShuttingDown перед любым postMessage.

Практическое исправление
Решение — флаги состояния:

let isShuttingDown = false;
process.on('SIGTERM', () => { isShuttingDown = true; });
if (!isShuttingDown) worker.postMessage({ ... });

Для надёжности — SharedArrayBuffer для атомарной синхронизации между основным потоком и Worker, если требуется строгий контроль.

Типичная ошибка
Многие путают: проблема не в доступе к process из Worker threads — Worker его не имеет. Корень — порядок микрозадач в основном потоке, где postMessage может быть отложен после обработки SIGTERM.

Вывод: Используйте флаги состояния перед асинхронными операциями в обработчиках сигналов — это предотвращает потерю данных при грейсфул шатдауне.

⁣Неявная блокировка Event Loop: как MapIterator убивает производительность в hot-path

Казалось бы, обычный for...of по Map — и вдруг Event Loop начинает тормозить. Проблема в скрытой аллокации MapIterator при деоптимизации V8. В hot-path это приводит к частому GC и блокировкам.

Почему это происходит
V8 в оптимизированном коде (TurboFan) может не аллоцировать итератор — он сохраняется на стеке или убирается escape analysis. Но деоптимизация из-за полиморфизма типов ключей (строки и числа), try/catch внутри цикла или превышения inline-лимитов заставляет создавать MapIterator в куче. В production это вызывает пинг-понг с GC.

Диагностика на практике
- --trace-gc — ищем аллокации MapIterator.
- --trace-deopt — смотрим причину: часто смешение типов ключей или нестабильный полиморфизм.
- Сравни for...of, map.forEach и ручной обход через Array.from(map.keys()) в бенчмарке. Разница может быть кратной.

Практический совет
В hot-path используй forEach, а не for...of. V8 может встроить его колбэк и избежать аллокации итератора. Если нужны ключи — закешируй их через Array.from и обходи обычным циклом.

Типичная ошибка
Не проверяешь стабильность типов ключей Map. Если ключи смешанные (строки и числа) — for...of гарантированно деоптимизируется. Зафиксируй типы или используй forEach.

Вывод: Аллокация MapIterator в hot-path из-за деоптимизации V8 — скрытая причина лагов Event Loop; замена for...of на map.forEach или кеширование ключей через Array.from устраняет проблему без ущерба для читаемости.

⁣structuredClone и Error с глубоким стек-трейсом: неявный убийца производительности в worker_threads

Передаёте Error через worker.postMessage()? Если стек-трейс глубокий — после цепочки асинхронных вызовов — V8 может незаметно блокировать поток на сериализации. Производительность падает линейно, а вы ищете причину в другом месте.

Почему это происходит

При вызове structuredClone V8 сериализует все перечислимые свойства объекта, включая .stack. Для Error с сотнями фреймов (длинные URL, аргументы функций) V8 парсит стековую строку целиком. Каждый фрейм проверяется, разбирается — и это происходит синхронно в вызывающем потоке. Пример: 5000 повторений .stack через repeat дают задержку ~100ms на postMessage.

Как диагностировать

Используйте --trace-event-categories или clinic flame. Ищите пики CPU в structuredClone. Сравните время postMessage с простым объектом против Error — разница в 10-50 раз при глубоком стеке. Типичная ошибка: разработчики грешат на дорогие вычисления, а на самом деле V8 тупо сериализует строчку.

Решение: не передавайте полный Error

Клонируйте только критичные поля: message, code, line, fileName. Для огромных стеков передавайте идентификатор ошибки, а полный стек собирайте локально. Можно упаковать Error в простой объект:

const safeError = {
  message: err.message,
  code: err.code,
  line: err.stack?.split('\n')[1]
};
worker.postMessage(safeError);

Production-кес: в нашем сервисе 20% CPU уходило на structuredClone ошибки с 1500+ фреймами. После замены на { msg: err.message } блокировка исчезла полностью.

Вывод: Не передавайте полный Error между воркерами при глубоких стеках — сериализация через structuredClone может незаметно съедать 10-20% CPU и блокировать поток.

⁣Диагностика и устранение неявного замедления TLS-рукопожатий из-за скрытой конкуренции за entropy pool в кластеризованных HTTPS-серверах

Если вы держите Node.js в кластере — через PM2 или встроенный cluster, — могли замечать странные задержки при HTTPS-соединениях. Вроде всё настроено, а рукопожатия то 5 мс, то 500+. Одна из неочевидных причин — драка за entropy pool.

Причина
Внутри каждого TLS-рукопожатия Node.js дёргает случайные числа для ключей. В Linux это /dev/urandom или getrandom(). Когда несколько воркеров одновременно лезут в один пул энтропии, начинаются блокировки. Особенно в контейнерах без аппаратного RNG — там стекло быстро заканчивается.

Симптомы: время рукопожатия плавает хаотично, иногда blocked for more than 120 seconds. strace покажет, что провал в crypto.randomFill().

Диагностика
Берите strace -e trace=getrandom -p <PID> -o entropy.log. Если вызовы висят дольше 1 мс — проблема. Проверьте скорость энтропии: dd if=/dev/urandom bs=1024 count=100 | pv.

Решения
* Отдельный seed для каждого воркера. При старте слать его через IPC из master:

process.on('message', (msg) => {
  if (msg.type === 'seed') {
    global._seed = msg.seed;
  }
});

* Для операций после старта — только асинхронный crypto.randomFill с callback. Синхронный вызов дёргает блокировку пула.
* На bare-metal поставьте haveged или rng-tools, в облаке — virtio-rng.

Типичная ошибка
Не используйте Math.random() для криптографии — это антипаттерн, который не решает проблему, а только создаёт уязвимости.

Вывод: Диагностика через strace и управление seed-ами — эффективный способ ускорить TLS без переписывания стека, но критично проверить нагрузку на entropy pool в кластере с 10+ воркерами.