Как можно использовать очередь в инфраструктуре

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

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

Как отвечать

Назовите сценарии с причиной:

• фоновые задачи: письма, отчёты, обработка файлов. Обработчик HTTP кладёт задачу и сразу отвечает;
• сглаживание пиков: очередь принимает всплеск, воркеры разбирают его в своём темпе, база не ложится;
• конкурирующие консьюмеры: несколько экземпляров читают одну очередь, масштабирование сводится к добавлению воркеров;
• fan-out: событие «заказ оплачен» читают биллинг, склад и уведомления, продюсер о них не знает;
• DLQ: сообщение, не обработанное за N попыток, уходит в отдельную очередь и не блокирует остальные.

Потом инструменты. RabbitMQ это брокер с маршрутизацией и удалением сообщения после подтверждения, клиент github.com/rabbitmq/amqp091-go. Kafka это лог: сообщения хранятся по сроку, консьюмеры двигают свой offset, порядок гарантирован только внутри партиции; клиенты segmentio/kafka-go, twmb/franz-go. Внутри процесса очередь заменяет буферизированный канал с пулом горутин, но задачи в нём теряются при рестарте.

Про гарантии: на практике это at-least-once, значит обработчик обязан быть идемпотентным (ключ дедупликации, INSERT ... ON CONFLICT DO NOTHING). Подтверждать сообщение нужно после обработки. Чтобы запись в базу и публикация события не разошлись, берут transactional outbox.

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

Называют Kafka очередью и ждут от неё удаления прочитанного и приоритетов. Это разные модели, и выбор между ними часть ответа.

Обещают exactly-once «из коробки». Транзакции Kafka покрывают только цепочку чтение, обработка, запись обратно в Kafka, а для внешней базы или API остаётся идемпотентность.

Забывают про корректное завершение: по SIGTERM воркер должен доработать текущее сообщение, подтвердить его и только потом выйти. Для этого signal.NotifyContext и отмена context.