Как происходит взаимодействие продюсера и консумера

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

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

Как отвечать

Начните с паттерна внутри процесса, потом перейдите к брокерам.

• queue.Queue: потокобезопасная очередь. С maxsize вызов put() блокируется на полной очереди, и быстрый продюсер не съедает память. Консьюмер берёт get() и отмечает task_done(), а join() ждёт обработки всего. Для остановки кладут сигнальное значение, например None, в Python 3.13 появился shutdown();
• asyncio.Queue: то же для корутин, потокобезопасной не является. Потоки из-за GIL годятся для ожидания ввода-вывода, CPU-нагрузку выносят в процессы через multiprocessing.Queue;
• RabbitMQ: продюсер публикует в exchange, тот раскладывает сообщения по очередям по routing key. Консьюмер подтверждает обработку через basic_ack, а basic_qos(prefetch_count=...) ограничивает число неподтверждённых сообщений у него на руках. В Python это pika или aio-pika;
• Kafka: продюсер пишет в партиции топика, ключ определяет партицию, порядок гарантирован только внутри неё. В группе консьюмеров каждую партицию читает один участник и фиксирует offset. Для надёжной записи продюсеру ставят acks=all.

Практичная гарантия в обоих брокерах это at-least-once: сообщение может прийти повторно, поэтому обработчик делают идемпотентным, например по ключу сообщения в базе.

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

Говорят, что консьюмер шлёт подтверждение продюсеру. Подтверждение получает брокер, продюсер о консьюмере ничего не знает, и в этом смысл развязки.

Ставят auto_ack=True. Сообщение считается доставленным до обработки, и падение консьюмера его теряет.

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