Есть ли опыт работы с message queue?

Что проверяют

Работали ли вы с асинхронным обменом руками, а не по статьям: какой брокер, что через него шло и какие проблемы решали. Следом почти всегда спрашивают про гарантии доставки: что будет, если обработчик упал посреди сообщения, и как не обработать один заказ дважды.

Как отвечать

Стройте ответ вокруг своего проекта. Каркас:

• контекст: брокер и клиент. В .NET это обычно RabbitMQ через RabbitMQ.Client или MassTransit, Kafka через Confluent.Kafka, Azure Service Bus. Зачем понадобилась очередь: развязать сервисы, сгладить пики, вынести долгую работу из HTTP-запроса;
• устройство консьюмера: BackgroundService в хосте, ручное подтверждение только после успешной обработки, ограничение prefetch, чтобы один воркер не забрал тысячу сообщений;
• надёжность: доставка «как минимум один раз», поэтому обработчик идемпотентный (таблица обработанных MessageId или уникальный ключ в базе). Повторы с задержкой, после нескольких неудач сообщение уходит в dead letter queue. Чтобы не терять события между записью в базу и публикацией, применяют transactional outbox, он есть и в MassTransit;
• эксплуатация: что мониторили (длина очереди, возраст самого старого сообщения, размер DLQ) и один реальный инцидент.

Цифры называйте свои, которые сможете объяснить: насколько упало время ответа API после выноса обработки в очередь, какой поток сообщений в секунду держали.

Если production-опыта нет, не сочиняйте. Скажите, что работали с внутрипроцессной очередью на System.Threading.Channels или с Hangfire, а RabbitMQ поднимали в Docker на пет-проекте, и перечислите, что там проверяли: падение консьюмера, повторную доставку, DLQ.

Где спотыкаются

Отвечают «да, RabbitMQ» и замолкают. Интервьюер вытягивает детали по одной, и ответ выглядит как строчка из резюме.

Уверены, что брокер сам избавит от дублей. Даже Kafka с транзакциями гарантирует exactly-once только внутри самой Kafka, а запись в вашу базу всё равно может повториться.

Не различают очередь и лог. Kafka хранит сообщения после чтения и позволяет перечитать топик, классическая очередь RabbitMQ удаляет сообщение после подтверждения. От этого зависит схема повторной обработки.