В 10:00 приходит тысяча задач. В 10:01 агент открывает тысячу LLM-вызовов и начинает душить API, базу и собственный бюджет. Autoscale, конечно. Что могло пойти не так.
Очередь задач AI-агента нужна, чтобы приём работы и исполнение жили с разной скоростью. Всплеск входа не обязан мгновенно становиться всплеском side effects.
Дальше появляются обычные инженерные вещи: concurrency limit, acknowledgements, retry, backpressure и dead letter queue. AI здесь ничего не отменяет.
Queue отделяет факт приёма от факта выполнения
API может быстро принять задачу, выдать operation ID и положить message в очередь. Worker заберёт её позже, когда есть capacity.
Это позволяет отдельно масштабировать producers и consumers. Пользователь видит статус queued/running/completed вместо зависшего HTTP request.
Amazon SQS — типичный пример managed message queue, где producers и consumers работают асинхронно.
Проверяемые источники: AWS — What is Amazon Simple Queue Service?
Concurrency ограничивают намеренно
Больше workers не всегда лучше. LLM provider имеет rate limits, downstream CRM — свои ограничения, а database pool вообще не впечатлён нашей любовью к параллелизму.
Я ставлю bounded concurrency на тип задачи и dependency. Если очередь растёт, это observable backlog, а не причина открыть бесконечное число запросов.
RabbitMQ flow control как раз существует, чтобы компоненты не принимали данные быстрее, чем система способна их переварить.
Проверяемые источники: RabbitMQ — Flow Control
Ack происходит после нужной гарантии
Если worker подтвердил message до side effect и упал, задача потеряна. Если подтвердил слишком поздно, message может прийти повторно.
Поэтому acknowledgement contract связывается с idempotency операции. Повторная доставка разрешена, повторный бизнес-результат — нет.
RabbitMQ подробно разделяет consumer acknowledgements и publisher confirms. Это обычная надёжность очередей, которая особенно важна для долгих agent runs.
Проверяемые источники: RabbitMQ — Consumer Acknowledgements and Publisher Confirms
Retry не должен блокировать очередь навсегда
Одна задача получает transient 503. Её можно отложить и повторить. Другая стабильно падает на invalid input — десятый retry ничего не улучшит.
Я храню attempt count, last error и next retry time. После бюджета задача уходит в terminal failure, а очередь продолжает работать.
Иначе один poison message начинает съедать capacity снова и снова. Классика.
Проверяемые источники: AWS — Using dead-letter queues in Amazon SQS
Dead letter queue — не кладбище без владельца
DLQ хранит сообщения, которые не удалось обработать по основной политике. AWS рекомендует использовать её для изоляции проблемных сообщений и последующего анализа.
Но просто складывать туда failures бессмысленно. Нужны reason code, correlation ID, исходная operation identity и понятный owner/recovery action.
После исправления message можно redrive только если операция безопасна при повторе и состояние downstream всё ещё допускает действие.
Проверяемые источники: AWS — Using dead-letter queues in Amazon SQS
Backlog должен иметь бизнес-дедлайн
Очередь успешно сохранила задачу на три дня. Технически надёжно. Только уведомление о встрече уже никому не нужно.
Я добавляю expires_at или business deadline. Worker перед исполнением проверяет, имеет ли операция смысл. Просроченная задача получает отдельный terminal state, а не выполняется ради красивой статистики completion.
И смотрю age of oldest message, throughput и DLQ rate. Если backlog растёт быстрее обработки, проблема уже видна до жалоб пользователей.
Для просроченных задач я также считаю отдельный reason code: capacity, dependency или неверно выбранный приоритет.
Проверяемые источники: AWS — Using dead-letter queues in Amazon SQS · AWS — What is Amazon Simple Queue Service?
Приоритеты очереди тоже требуют starvation policy
Срочные задачи можно поставить выше обычных. Потом приходит бесконечный поток срочных, и low-priority сообщения лежат сутки.
Я бы задавал ограниченные priority classes и следил за age внутри каждой. Иногда нужен aging: старая обычная задача постепенно получает больше шансов на выполнение.
Если бизнес действительно разрешает никогда не выполнять низкий приоритет при нагрузке, лучше зафиксировать expiry и честно завершать его, а не держать вечный backlog.
Для long-running agent job я также сохраняю lease или heartbeat. Worker умер — задача не должна вечно висеть `running`. После timeout другой consumer может забрать её только через тот же idempotency contract. Иначе recovery от падения worker создаст второй side effect вместо восстановления обработки.
Проверяемые источники: AWS — Using dead-letter queues in Amazon SQS · AWS — What is Amazon Simple Queue Service?
Короткие вопросы перед production
Зачем AI-агенту очередь задач?
Чтобы отделить приём работы от долгого выполнения, контролировать concurrency и безопасно переживать всплески нагрузки или временные сбои зависимостей.
Что такое dead letter queue?
Это отдельная очередь для сообщений, которые не удалось обработать по основной retry policy. Она должна иметь owner, reason code и понятный recovery process.
Как backpressure связан с AI?
AI-вызовы и tools имеют ограниченную пропускную способность. Backpressure не позволяет входному потоку бесконтрольно создавать больше параллельной работы, чем система может устойчиво выполнить.
Проверка у меня такая: дайте входу кратковременный десятикратный всплеск. Система должна накопить backlog, удержать concurrency, не создать дубли и потом спокойно догнать очередь. Если вместо этого всё одновременно зовёт LLM — очередь пока декоративная.
Смежные контуры, которые стоит прогнать отдельно для «dead letter queue»: Retry webhook: timeout, backoff и circuit breaker при сбое API · Idempotency key для webhook: как не создать дубль сделки при повторной доставке · LLM observability: как мониторить AI-агента в production.