Розничная платформа обрабатывает многоэтапные рабочие процессы заказов. Каждый заказ генерирует цепочку связанных сообщений (заказ создан, платеж авторизован, товары зарезервированы), которые должны обрабатываться в порядке OrderId несколькими подписчиками. Когда обработчик обрабатывает сообщение «заказ создан», он должен атомарно отправить две команды нижестоящим службам или выполнить откат, если обработка не удалась. «Ядовитые» сообщения должны быть изолированы без их потери. Какой дизайн обмена сообщениями вы бы порекомендовали?

Правильный вариант — это Azure Service Bus Topic с включенными сессиями (sessionId=OrderId). Сессии обеспечивают обработку связанных сообщений в правильном порядке (по OrderId), что критически важно для многоэтапных рабочих процессов. Транзакции Service Bus гарантируют атомарность: либо входящее сообщение завершается и исходящие отправляются, либо происходит откат, предотвращая частичные обновления. Подписки для каждой нижестоящей службы позволяют нескольким потребителям получать сообщения. Dead-letter subqueue автоматически изолирует «ядовитые» сообщения, не теряя их. Остальные варианты не подходят: Очередь Azure Service Bus без сессий не гарантирует порядок обработки связанных сообщений. Обнаружение дубликатов не заменяет упорядочивание. Azure Storage Queue не поддерживает сессии, транзакции и встроенное dead-lettering, что затрудняет обработку сложных сценариев и «ядовитых» сообщений. Azure Event Grid не гарантирует порядок событий и доставку at-most-once, что не подходит для сценариев, требующих строгой последовательности и надежности. Топик Azure Service Bus без сессий не обеспечивает упорядоченную обработку связанных сообщений. Отключение dead-lettering приведет к потере «ядовитых» сообщений.