<b>DLQ — не свалка ошибок, а буфер для разборов, иначе система начнёт гнить молча</b>

<b>DLQ — не свалка ошибок, а буфер для разборов, иначе система начнёт гнить молча</b>

Dead Letter Queue нужна не для того, чтобы “потом как-нибудь посмотреть”. Она фиксирует события, которые не прошли обработку после N ретраев: битый JSON, несовместимая схема, таймаут внешнего API, дубли, отказ БД. Если в основной очереди это просто очередной фейл, то в DLQ уезжает конкретный payload вместе с метаданными: причина, количество попыток, timestamp, correlation_id, версия хендлера.

Нормальная схема выглядит так: consumer ловит ошибку → классифицирует её → решает, retryable она или fatal. Retryable идёт обратно в очередь с backoff и jitter, fatal — в DLQ. Важно не класть туда всё подряд: если временно упал downstream, DLQ не спасает, он только скрывает деградацию. Ретрай-политика решает всё, а DLQ — это последняя линия обороны, не костыль для плохого API.

Для DLQ нужен отдельный процесс разбора:
• валидируем payload и схему
• сверяем идемпотентность по event_id
• смотрим, не сломан ли контракт
• даём кнопку replay после фикса
• ограничиваем ручной рефайловый зоопарк через ACL и аудит

Хорошая практика — хранить в DLQ не только тело события, но и причину отказа, stack trace, имя обработчика и хэш полезной нагрузки. Тогда через сутки вы не гадаете, почему событие умерло, а видите цепочку. Идемпотентность — это не роскошь, а база: без неё replay из DLQ легко создаст дубликаты и тихий хаос.