В каждом втором проекте наступает момент, когда отправку писем, генерацию PDF или синхронизацию с CRM нельзя больше делать прямо в обработчике запроса. Пользователь ждёт, таймауты растут, а повторить упавшую задачу некому.
Зачем вообще очередь
Очередь отделяет «принять задачу» от «выполнить задачу». API отвечает за 50 мс, а воркер спокойно делает тяжёлую работу и повторяет её при сбое.
- долгие операции не блокируют ответ;
- упавшие задачи повторяются с задержкой;
- нагрузку можно сгладить, добавив воркеров.
Очередь на Postgres
Если база уже есть, начните с таблицы задач и SELECT … FOR UPDATE SKIP LOCKED. Это сотни задач в секунду без новой инфраструктуры.
Добавьте индекс по (status, run_at), иначе выборка задач начнёт тормозить уже на десятках тысяч строк.
Когда переходить на RabbitMQ
Отдельный брокер окупается, когда задачи нужно маршрутизировать между сервисами, поток превышает тысячи сообщений в секунду или важна доставка в реальном времени.
Самая дешёвая инфраструктура — та, которую не нужно поднимать. Переезжайте на брокер, когда упрётесь в базу, а не заранее.
Чек-лист перед переездом
- Замерьте пропускную способность текущей очереди.
- Опишите типы сообщений и их получателей.
- Решите, что делать с сообщениями, которые не удалось обработать (dead letter).
Итог
Начинайте с Postgres, следите за метриками и переходите на брокер по факту, а не «на вырост». В следующей статье разберу, как мы перенесли 2 млн задач в день на RabbitMQ без простоя.