Продолжаем тему ненадежности.
Начало было здесь

Самый надежный брокер бесполезен, если producer или consumer ненадежен. Именно на концах коммуникации - в точках производства и потребления сообщений - происходят самые коварные и сложные для отладки сбои.

Анатомия ненадежного consumer'а. Как все ломается


Сценарий катастрофы
Представьте consumer, который:
1. Получает сообщение из очереди
2. Начинает его обработку
3. Встречает временную ошибку (сеть, БД, внешний API)
4. Падает, не подтвердив обработку (не отправляет ack)
5. Сообщение возвращается в очередь
6. Процесс повторяется бесконечно

Результат: Очередь забита одним и тем же "битым" сообщением, система потребляет 100% CPU на бесполезную работу, новые сообщения не обрабатываются.

🆘 Корневые проблемы
1. "Зависшие" сообщения — сообщения, которые не могут быть обработаны, но и не могут быть отклонены окончательно

2. Бесконечные retry — циклические повторные попытки без прогресса

3. Забитые очереди — когда "мертвые" сообщения блокируют поток новых данных

Решения

✳️ Dead Letter Queue как система спасения
Dead Letter Queue - это специальная очередь для сообщений, которые не могут быть обработаны после исчерпания всех попыток или при установке наличия постоянной проблемыс данным сообщением. Как правило, такие сообщения требуют ручного разбора, поэтому эта очередь "обложена" событиями мониторинга.

Что класть в DLQ
1. Оригинальное сообщение полностью
2. Контекст ошибки (тип, сообщение)
3. Метаданные обработки (количество попыток, timestamp)
4. Заголовки из оригинального сообщения

Другие решения рассмотрим далее.