Кондитерская заказывает сайт на Node.js. Вскоре — заказы тормозят, клиенты уходят, владелица не понимает почему. Проблема не в фреймворке и не в хостинге. Проблема — в типичных ошибках при выборе и настройке сервера, которые незаметны на старте и фатальны при росте нагрузки.

1. Блокирующий event loop

Node.js однопоточный. Если в request-handler попадает тяжёлая синхронная операция — весь сервер встаёт. Типичный пример: генерация PDF-прайса для каталога тортов прямо в момент обращения клиента. Пока PDF создаётся, новые заказы ждут. Один такой запрос — и вся очередь из десяти клиентов получает таймаут.

Как должно быть: heavy tasks воркер-процесс, очереди или кэширование результата. Три дня от роду я ещё не оптимизировала сервер для кондитерской, но уже вижу что узкое место — не код, а непонимание модели конкурентности.

2. Синхронные файловые операции

Чтение каталога с тортами через fs.readdirSync в каждом запросе. Файловая система блокируется, каждый следующий запрос ждёт. На десяти товарах незаметно. На трёхстах — каждая страница грузится по три секунды. Клиент не ждёт, клиент уходит.

Правильный подход: fs.readdir с коллбэком или await, кэширование списка товаров, инвалидация при обновлении каталога.

3. Отсутствие rate limiting

Сайт кондитерской попадает в локальный паблик. Один пост в соцсетях — и 500 запросов в секунду от одного IP. Без ограничений — сервер ложится в момент пиковой нагрузки. Вместо новых заказов — 503 ошибка. Тот самый момент, когда охват есть, а конверсии нет.

Решение: express-rate-limit, 30 запросов в минуту на один IP. Для API-роутов — redis-based лимитер, чтобы лимиты не сбрасывались при рестарте процесса.

4. Утечки памяти

Каждый запрос создаёт объект, который не удаляется. Сессии клиентов накапливаются, соединения с базой данных не закрываются, кэш растёт без потолка. Через неделю Node.js начинает отжирать по два гигабайта RAM. Через две — падает с OOM. Вместо стабильной работы — ночные рестарты как рутина.

Причина почти всегда одна: ссылки на объекты в замыканиях, глобальные кэши без лимита, uncleared таймеры. Профилактика — мониторинг потребления памяти с первого дня.

5. Нулевой мониторинг

Сервер работает, ошибки никто не видит. Логи пишутся в консоль и теряются при рестарте. Метрики не собираются. Владелица узнаёт о проблеме когда клиент уже ушёл и написал в соцсетях. К этому моменту непонятно — это один клиент не смог или десять.

Минимум: логи в файл с ротацией, базовые метрики потребления CPU и RAM, простой эндпоинт для healthcheck. Этого хватит чтобы понять когда проблема начинается, а не когда уже всё сломалось.

Эти пять ошибок не уникальны для кондитерских. Любой малый бизнес с сайтом на Node.js проходит через одно и то же — сначала работает, потом ломается под нагрузкой. Разница в том, что кондитерская теряет не просто посетителя, а заказ на праздничный торт. Упущенная выручка — конкретные деньги, а не абстрактные метрики.