Загружаем паттерны…

📬

Очередь сообщений(MQ)

Асинхронная система передачи сообщений, обеспечивающая слабосвязанную коммуникацию между ИИ-агентами и сервисами в распределённых агентных системах

Сложность: highМультиагентные системы

За 30 секунд

Что это: Агенты отправляют сообщения в очереди вместо прямых вызовов друг друга, что обеспечивает асинхронную работу и развязывает зависимости между сервисами.
Когда применять: Нескольким агентам нужно координировать работу без взаимных блокировок, справляться с переменной нагрузкой или восстанавливаться после сбоев, не теряя задач.
Осторожно: Порядок сообщений и обработка дубликатов усложняются; отлаживать распределённые сбои сразу в очереди, у производителя и у потребителя значительно труднее.

Спросите ИИ-эксперта об этом паттерне

Откроет ассистента с готовым вопросом. Вы проверите его перед отправкой.

Получить этот каталог как MCP-сервер Настроить промпт для этого паттерна

Asynchronous agent communication
Message persistence and durability
Priority-based task distribution
Multi-agent coordination
Fault tolerance and recovery
Scalable load balancing
Event-driven workflows
Dead letter queue handling

The Agent Architect

Один паттерн, один компромисс, одна история сбоя в продакшене. Короткий еженедельный брифинг для тех, кто строит агентные системы.

Одно письмо в неделю, отписка в один клик. Адрес используется только для рассылки брифинга.

Источники

Статьи, спецификации и репозитории, на которых основан этот паттерн.

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services (2001)
Kafka: a Distributed Messaging System for Log Processing (NetDB 2011)
Kafka versus RabbitMQ (2017)arXiv:1709.00333

От инженера, создавшего этот каталог

Проведите ревью архитектуры ваших агентов

На этой странице описан один паттерн. Ваша система использует десятки, и большинство сбоев возникает на стыках. Мы разберём весь дизайн по 288 паттернам каталога: архитектура, надёжность, оценка и стоимость, каждая находка связана с паттерном, который её устраняет.

€750 вместо €1 500, одна неделя, письменный отчёт и разбор в звонке, до 30 сентября

Смотреть ревью

Паттерны

Загружаем паттерны…

Паттерны и методы проектирования

Загружаем паттерны…

📬

Очередь сообщений(MQ)

Сложность: highМультиагентные системы

За 30 секунд

Что это: Агенты отправляют сообщения в очереди вместо прямых вызовов друг друга, что обеспечивает асинхронную работу и развязывает зависимости между сервисами.
Когда применять: Нескольким агентам нужно координировать работу без взаимных блокировок, справляться с переменной нагрузкой или восстанавливаться после сбоев, не теряя задач.
Осторожно: Порядок сообщений и обработка дубликатов усложняются; отлаживать распределённые сбои сразу в очереди, у производителя и у потребителя значительно труднее.

Спросите ИИ-эксперта об этом паттерне

Откроет ассистента с готовым вопросом. Вы проверите его перед отправкой.

Получить этот каталог как MCP-сервер Настроить промпт для этого паттерна

Основной механизм

Очереди сообщений обеспечивают асинхронное, слабосвязанное взаимодействие между производителями и потребителями через долговечные очереди. Брокеры дают гарантии доставки (at-least-once, at-most-once, иногда exactly-once), варианты упорядочивания (по партиции/группе), подтверждения, повторы и обработку недоставленных сообщений. Распространённые реализации: Apache Kafka (партиции на основе лога, группы потребителей), RabbitMQ/AMQP (очереди, обменники, привязки), облачные очереди AWS SQS и Google Pub/Sub, NATS JetStream и Redis Streams.

Процесс / Шаги

Производитель публикует сообщение (при необходимости с ключом для упорядочивания или партиционирования).
Брокер сохраняет/ставит в очередь и реплицирует (согласно настройкам), предоставляя лаг/смещения потребителей или глубину очереди.
Потребитель забирает/получает сообщения с prefetch и управлением потоком; обрабатывает их в рамках таймаута и бюджета.
При успехе подтверждать; при сбое повторять с backoff или направлять в очередь недоставленных сообщений (DLQ).
Операторы отслеживают метрики и настраивают партиции, потребителей и квоты ради пропускной способности и SLO.

Лучшие практики

Проектировать идемпотентных потребителей и применять ключи идемпотентности для безопасной обработки дубликатов.

Ограничивать обработку таймаутами; применять экспоненциальный backoff с джиттером; ограничивать повторы и использовать DLQ.

Явно выбирать семантику доставки; документировать гарантии порядка для каждого топика/очереди.

Использовать группы потребителей и партиции/шарды для горизонтального масштабирования; избегать горячих ключей.

Применять обратное давление: настраивать prefetch и управление потоком; при необходимости пакетировать; ограничивать число сообщений в обработке.

Проверять схемы сообщений (например, Avro/Protobuf/JSON Schema); использовать реестр схем и правила совместимости.

Изолировать побочные эффекты; применять шаблон Outbox для атомарности БД→очередь; обеспечивать exactly-once там, где это поддерживается.

Шифровать при передаче и хранении; обеспечивать авторизацию (RBAC, IAM) и квоты по арендаторам.

Держать сообщения небольшими; крупные блобы хранить снаружи и передавать ссылки; сжимать осмотрительно.

Наблюдать: выдавать лаг, глубину очереди, число повторных отправок, причины сбоев; добавить трассировку по ID сообщений.

Когда НЕ использовать

Синхронные пути запрос/ответ со сверхнизкой задержкой, где накладные расходы очереди ломают SLO → предпочтительнее прямой RPC (gRPC/REST).

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

Простые, тесно связанные интеграции, где очередь добавляет эксплуатационную сложность без явной пользы.

Типичные ошибки

Полагаться на неявный порядок между партициями/очередями; непоследовательно назначать ключи сообщениям.

Неидемпотентные побочные эффекты при повторах → дубликаты и повреждение данных.

Неограниченный рост очередей и лаг потребителей из-за отсутствия обратного давления или недостаточного масштабирования.

Штормы повторов и эффект «стада»; нет предохранителей и backoff с джиттером.

Крупные payload в брокере; отсутствие стратегии эволюции схем приводит к поломке потребителей.

Ключевые особенности

Семантика доставки: at-least-once / at-most-once / exactly-once (зависит от платформы).

Управление порядком: ключи партиций, FIFO-группы, ключи упорядочивания.

Долговечность и репликация; политики подтверждения и повторной доставки.

DLQ, TTL и отложенная либо запланированная доставка.

Группы потребителей, prefetch/управление потоком и обратное давление.

Реестр схем и режимы совместимости; версионирование сообщений.

KPI / Метрики успеха

Сквозная задержка p50/p95/p99; задержка публикации и потребления.

Пропускная способность (сообщений/с, МБ/с) по топикам/очередям и группам потребителей.

Лаг потребителей и глубина очереди; возраст старейшего сообщения; доля повторных отправок/DLQ.

Доли повторов и дубликатов; доли успешной/неуспешной обработки; MTTR.

Состояние брокера: ISR/репликация, баланс лидеров партиций, использование хранилища.

KPI стоимости: исходящий трафик, хранилище, плата за запросы (для управляемых сервисов).

Использование токенов / ресурсов

Профиль ресурсов: CPU для сериализации/сжатия и координации брокера; память для буферов; дисковый ввод-вывод для долговечных логов; сеть для репликации и клиентского трафика.

Оптимизировать пакетированием и сжатием; правильно подбирать число партиций и параллелизм потребителей; ограничивать размер сообщений (например, SQS 256 КБ, Pub/Sub 10 МБ, Kafka настраивается).

Не встраивать крупные блобы; хранить их снаружи и отправлять ссылки; применять квоты и лимиты запросов по арендаторам.

Лучшие сценарии применения

Развязка микросервисов; асинхронные процессы; обработка фоновых задач.

Событийные архитектуры и веерная обработка; журналы аудита и событий.

Выравнивание нагрузки и сглаживание всплесков; управление обратным давлением у нижестоящих систем.

Буферизация между регионами и устойчивость к прерывистой связи.

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Apache Kafka, RabbitMQ, AWS SQS, Google Pub/Sub, NATS JetStream, Redis Streams
Клиентские SDK: клиенты librdkafka/Confluent, Sarama (Go), Spring Kafka/AMQP, aio-pika, AWS SDK
Очереди заданий: Celery, Sidekiq, Resque, BullMQ, RQ

Сообщество и обсуждения

Asynchronous agent communication
Message persistence and durability
Priority-based task distribution
Multi-agent coordination
Fault tolerance and recovery
Scalable load balancing
Event-driven workflows
Dead letter queue handling

The Agent Architect

Одно письмо в неделю, отписка в один клик. Адрес используется только для рассылки брифинга.

Источники

Статьи, спецификации и репозитории, на которых основан этот паттерн.

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services (2001)
Kafka: a Distributed Messaging System for Log Processing (NetDB 2011)
Kafka versus RabbitMQ (2017)arXiv:1709.00333

От инженера, создавшего этот каталог

Проведите ревью архитектуры ваших агентов

€750 вместо €1 500, одна неделя, письменный отчёт и разбор в звонке, до 30 сентября

Смотреть ревью

Загружаем паттерны…

Очередь сообщений(MQ)

За 30 секунд

Спросите ИИ-эксперта об этом паттерне

Очередь сообщений: Обзор

The Agent Architect

Источники

Проведите ревью архитектуры ваших агентов

Паттерны

Загружаем паттерны…

Паттерны и методы проектирования

Загружаем паттерны…

Очередь сообщений(MQ)

За 30 секунд

Спросите ИИ-эксперта об этом паттерне

Основной механизм

Процесс / Шаги

Лучшие практики

Когда НЕ использовать

Типичные ошибки

Ключевые особенности

KPI / Метрики успеха

Использование токенов / ресурсов

Лучшие сценарии применения

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Сообщество и обсуждения

Очередь сообщений: Обзор

The Agent Architect

Источники

Проведите ревью архитектуры ваших агентов

Паттерны

Паттерны и методы проектирования

Загружаем паттерны…

Паттерны и методы проектирования

Основной механизм

Процесс / Шаги

Лучшие практики

Когда НЕ использовать

Типичные ошибки

Ключевые особенности

KPI / Метрики успеха

Использование токенов / ресурсов

Лучшие сценарии применения

Ссылки и дополнительное чтение

Научные статьи

Руководства по реализации

Инструменты и библиотеки

Сообщество и обсуждения

Паттерны и методы проектирования