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

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

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

Как отвечать

Отвечайте на своём проекте: что отправляли, через какой брокер, какой был поток сообщений, какие случались сбои. Цифры называйте свои и только те, в которых уверены.

Каркас ответа:

• зачем очередь: API маркетплейсов ограничивают частоту запросов и бывают недоступны, а пользователь не должен ждать их ответа. Сервис фиксирует изменение, кладёт сообщение и отвечает сразу, отдельный потребитель отправляет данные в своём темпе;
• инструменты: RabbitMQ или Kafka, в .NET через MassTransit или напрямую через RabbitMQ.Client и Confluent.Kafka. Внутри одного процесса хватает BackgroundService с System.Threading.Channels, для отложенных задач берут Hangfire;
• надёжность: transactional outbox, чтобы запись в базу и публикация не расходились (у MassTransit есть готовый outbox для EF Core), повторы с экспоненциальной задержкой на ответы 429 и 5xx, dead letter очередь для сообщений, которые так и не прошли;
• дубли: потребитель идемпотентный, с проверкой по messageId или ключу идемпотентности, а для остатков и цен отправляется последнее состояние, а не дельта;
• порядок: для обновлений одного товара он важен, в Kafka его обеспечивает ключ партиции по артикулу.

Если очередей в проекте не было, скажите честно, как это было устроено (синхронные вызовы, cron, Hangfire), какие проблемы это давало и как бы вы перевели интеграцию на брокер. Это лучше пересказа статьи.

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

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

Обещают доставку ровно один раз. Для побочного эффекта во внешнем API гарантия максимум «хотя бы один раз», даже если брокер умеет транзакции, дальше всё решает идемпотентность.

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