Пример чек-листа для системного аналитика, чтобы зафиксировать требования к RabbitMQ на проекте.

1. Контекст и цель

• Какой бизнес-сценарий решаем.
• Почему выбран асинхронный обмен, а не синхронный.
• Какие системы участвуют: источник, брокер, потребитель.
• Это событие, команда или интеграционное сообщение.

2. Сценарий обмена

• Что отправляется: событие, запрос, уведомление, команда.
• Кто публикует сообщение.
• Кто его читает.
• Сообщение одноадресное или может читать несколько потребителей.
• Нужен ли ответ на сообщение.

3. Топология RabbitMQ

• Какой exchange используется: direct, topic, fanout, headers.
• Какой routing key используется.
• Какие очереди создаются.
• Какие binding’и между exchange и queue.
• Нужны ли дополнительные exchange или промежуточные очереди.

4. Требования к сообщению

• Формат сообщения: JSON, XML, Avro, другое.
• Обязательные и необязательные поля.
• Типы и ограничения полей.
• Какие headers обязательны.
• Есть ли correlation id, message id, trace id.
• Размер сообщения, если есть ограничения.
• Версионирование контракта.

5. Требования к очереди

• Очередь постоянная или временная.
• Нужна ли durable-очередь.
• Нужна ли auto-delete.
• Нужна ли exclusive-очередь.
• Нужен ли TTL для сообщений.
• Нужен ли priority.
• Нужен ли лимит длины очереди.
• Нужна ли отдельная очередь для ошибок.

6. Доставка и надежность

• Какая гарантия доставки нужна: at-most-once, at-least-once, exactly-once.
• Что считается успешной обработкой.
• Когда сообщение можно удалить из очереди.
• Нужны ли подтверждения доставки.
• Что делать при повторной доставке.
• Допустимы ли дубли сообщений.
• Как обрабатывать недоступность потребителя.

7. Ошибки и ретраи

• Сколько раз повторять попытку.
• Через какие интервалы делать retry.
• Что делать после исчерпания retry.
• Нужен ли dead-letter queue.
• Какие ошибки считаются бизнесовыми, а какие техническими.
• Кто отвечает за ручную обработку сообщений из DLQ.
• Нужно ли логировать причину попадания в ошибочную очередь.

8. Производительность и нагрузка

• Ожидаемый объем сообщений в секунду.
• Пиковая нагрузка.
• Допустимая задержка доставки.
• Есть ли требования к порядку обработки.
• Нужна ли параллельная обработка.
• Есть ли ограничения по потреблению ресурсов.

9. Безопасность и доступы

• Кто имеет право публиковать сообщения.
• Кто имеет право читать очереди.
• Нужна ли аутентификация и авторизация.
• Нужен ли шифрованный канал.
• Есть ли чувствительные данные в сообщении.
• Нужно ли маскирование или исключение персональных данных.

10. Мониторинг и сопровождение

• Какие метрики нужны: длина очереди, lag, rate, ошибки, DLQ.
• Какие алерты нужны и на какие пороги.
• Кто владелец очереди и кто дежурит.
• Где смотреть логи и трассировку.
• Как понять, что интеграция сломалась.
• Как выполняется ручной reprocess.

11. Документация и согласование

• Описан ли контракт сообщения.
• Есть ли схема обмена.
• Согласованы ли названия exchange, queue и routing key.
• Согласованы ли правила версионирования.
• Согласованы ли retry, DLQ и порядок обработки ошибок.
• Понятно ли, кто утверждает изменения контракта.

12. Вопросы, которые стоит задать

• Что будет, если потребитель недоступен?
• Можно ли терять сообщения?
• Можно ли получать дубликаты?
• Нужен ли порядок обработки?
• Нужен ли один или несколько потребителей?
• Что делать с сообщением при ошибке в бизнес-логике?
• Нужен ли DLQ и кто ее разбирает?
• Как будет происходить изменение формата сообщения?

Короткий шаблон фиксации

Можно прямо в требованиях фиксировать так:

• Источник сообщения:
• Получатель сообщения:
• Тип обмена:
• Exchange:
• Routing key:
• Queue:
• Формат сообщения:
• Обязательные поля:
• Retry policy:
• DLQ: ...
• TTL: ...
• Требования к порядку: ...
• Требования к дублированию: ...
• Метрики и алерты: ...
• Ответственный за сопровождение: ...