DLQ — не свалка ошибок, а отдельный контур для событий, которые нельзя терять

DLQ — не свалка ошибок, а отдельный контур для событий, которые нельзя терять

Если хендлер не смог обработать полезную нагрузку, событие нельзя просто выбросить в лог и забыть. Правильная схема: основной consumer делает 1–3 попытки, потом публикует сообщение в DLQ с причиной падения, количеством ретраев и исходными метаданными. Смотрим в тело запроса: без оригинального payload потом невозможно понять, это битый JSON, невалидная схема или упавшая зависимость.

DLQ должен быть изолирован от основного пайплайна. У него свой retention, своя очередь на разбор и свой интерфейс для ручного reprocess. Полезно сохранять такие поля: event_id, source, received_at, error_class, stack, headers, payload_hash. Если не хранить hash, идемпотентность начинает жить своей отдельной жизнью: одно и то же событие можно случайно поднять дважды.

Нельзя отправлять в DLQ все подряд. 4xx от валидации — туда, 5xx от временного сбоя — лучше в retry queue с backoff. Иначе вы превращаете DLQ в помойку временных отказов и теряете сигнал. Ретрай-политика решает всё: сначала мягкие повторы, потом quarantine, потом ручной разбор. Для ручного replay нужен отдельный воркер, который проверяет дедупликацию перед повторной публикацией.

Минимум для продакшена: шифруем чувствительные поля, ограничиваем доступ к чтению DLQ, логируем каждое ручное вмешательство и ставим алерт, если очередь растёт быстрее нормы. Иначе ночью придётся ловить 5xx на ровном месте уже не в основном потоке, а в собственном разборе аварий.