Клиент нажимает «Оформить заказ» — и сайт висит пять секунд. В этот момент в коде отправляется письмо о заказе, уведомление менеджеру и запрос в CRM, но пользователь этого не видит: он просто уходит к конкурентам. По данным Google, вероятность отказа растёт на 32%, если страница грузится дольше трёх секунд. Проблема решается архитектурно — «тяжёлые» операции уводятся в фоновые задачи и очереди. В статье объясняем, как это устроено в Node.js, какие задачи выносить в фон и что бизнес получает в цифрах.
Фоновые задачи простыми словами: официант и кухня
Представьте ресторан, где официант сам ходит на кухню готовить каждое блюдо. Пока он жарит стейк, остальные столики ждут. Именно так работает сайт без очередей: запрос пользователя «залипает», пока выполняется медленная операция.Фоновая схема устроена иначе. Веб-сервер принимает действие пользователя и мгновенно возвращает ответ: «Заказ принят, подтверждение придёт на почту». А «готовкой» занимаются отдельные процессы-обработчики (воркеры), которые берут задачи из общей очереди и выполняют в своём темпе. Пользователь получает скорость, а тяжёлая работа всё равно делается — просто не в момент ожидания клиента.Какие задачи стоит выносить в очередь
Правило простое: если операция занимает дольше 200–300 мс и не нужна пользователю прямо сейчас — это кандидат в фоновые задачи.- Рассылки и уведомления — письма о заказах, SMS, push, сообщения в Telegram. Отправка одного письма через SMTP занимает 1–5 секунд, а рассылка на 5 000 адресов «в лоб» уронит сайт.
- Генерация отчётов — выгрузки в Excel и PDF. Отчёт по продажам за квартал может собираться 30–60 секунд.
- Обработка файлов — ресайз изображений, создание миниатюр, парсинг прайс-листов на 10 000 строк.
- Обмен с CRM и 1С — синхронизация заказов и остатков, если внешняя система отвечает медленно (а она часто отвечает медленно).
- Массовые операции — обновление цен по всему каталогу, импорт товаров, применение скидок к акции.
Как это устроено в Node.js
Node.js обрабатывает запросы в одном потоке — это его сила и слабость одновременно. Одна тяжёлая синхронная операция блокирует весь сервер, и страдают все пользователи, включая тех, кто просто листает каталог.Классический стек для очередей: Redis как быстрое хранилище задач и библиотека BullMQ поверх него. Задачи складываются в Redis, воркеры забирают их и выполняют параллельно с основным сайтом. Для регулярных операций — «отчёт каждый понедельник в 9:00» — используется планировщик или встроенные repeatable jobs BullMQ. Если добавлять Redis не хочется, на небольших нагрузках очередь можно организовать на PostgreSQL.Что это даёт в цифрах: кейс интернет-магазина
Сценарий из практики: магазин с ~2 000 заказов в день, при оформлении заказа синхронно отправлялись письмо клиенту, уведомление менеджеру и запрос в CRM. Итог — оформление занимало 4–6 секунд, а при сбоях почтового сервера растягивалось до 30 секунд и заканчивалось ошибкой.После выноса отправки в очередь ответ сервера на оформление — 350–400 мс. Письма уходят с контролируемой скоростью 100 штук в минуту (почтовые провайдеры режут тех, кто шлёт без ограничений, и быстро отправляют в спам), а упавшая задача автоматически повторяется. Через месяц конверсия в оформленный заказ выросла примерно на 8% — без изменения дизайна и функционала, только за счёт скорости.Что обязательно настроить
Очередь — это не просто «кинуть задачу в Redis». Чтобы система работала надёжно, нужны:- Повторные попытки — если почтовый сервер недоступен, задача должна повториться через 1, 5, 30 минут, а не исчезнуть навсегда.
- Приоритеты — письмо о новом заказе важнее еженедельной рассылки; очередь обрабатывает срочное первым.
- Идемпотентность — задача при сбое может выполниться дважды, и код должен это переживать без двойных списаний и двойных писем.
- Мониторинг — панель вроде Bull Board и алерты в Telegram при накоплении упавших задач. Очередь без мониторинга — чёрный ящик.
- Лимит параллельности — сколько задач выполняется одновременно, чтобы не положить сторонний API или собственную базу.
Частые ошибки при внедрении
Первая — хранить очередь в памяти процесса: перезапуск сервера — и все несформированные отчёты и письма пропали без следа. Вторая — запускать воркеры на том же сервере, что и сайт, без ограничения ресурсов: тяжёлая обработка файлов снова съедает процессор, и пользователи чувствуют тормоза.Третья ошибка — забывать про обратную связь: отчёт «улетел в фон», а человек сидит и ждёт загрузки файла. Правильно — показывать статус («готовим, пришлём на почту») и отдавать ссылку по готовности. Четвёртая — отсутствие ограничений при массовых рассылках: 5 000 писем за минуту — гарантированный бан отправителя у почтового провайдера.Признаки, что вашему проекту нужна очередь
- Оформление заказа, регистрация или отправка формы занимает заметно дольше секунды.
- Вебхуки от CRM или платёжных систем иногда падают по таймауту — они требуют ответ за 3–5 секунд.
- Массовые операции (импорт, рассылка) запускаются «ночью и вручную», потому что днём сайт не выдерживает.
- После сбоя или обновления часть писем и уведомлений теряется безвозвратно.
- Отчёты в админке падают по таймауту nginx (обычно 60 секунд).