Недавно большой интерес у коллег SRE вызвала DLQ. Разберем немного подробнее термины, которые упоминались ранее, и посмотрим на DLQ под другим углом.

🔻Механизм изоляции «ядовитых» сообщений

Ядовитым называют то сообщение, которое даже при многократных попытках обработки не может принести пользу Консьюмеру. Например, отсутствие обязательного поля ведет к тому, что будет падать при каждом ретрае и может блокировать очередь.
Лаг растет. Система деградирует. Занавес...

Под механизмом понимается логика: если N попыток обработки стали неуспешными - в DLQ. Проблема локализуется, система не стопорится.

🔻 Инструмент обнаружения регрессий и проблем интеграции

Всем знакомо слово регресс и регрессионное тестирование. Представьте, что вы обновили сервис, и вдруг старые продюсеры начинают присылать сообщения, которые новый код не понимает.

И если DLQ разрослась и ошибки однотипные, то DLQ становится первым сигналом нарушения контракта. Поэтому вешайте на DQL анализ типов ошибок и алерт на рост.

DLQ показывает не только технические ошибки.
Он показывает семантические конфликты между командами.

🧲 Как DLQ помогает улучшать схемы?

1. Поможет выявить неоднозначные поля (например, где нет четкого enum-списка или версий)

2. Выявит обязательные поля

3. Ошибки совместимости и версионирования

4. (на мой взгляд самый главный пункт) Дает повод проанализировать и улучшить retry-стратегию