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

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

Если событие не прошло обработку, не надо бесконечно крутить его в основном пайплайне. Правильная схема: основной consumer валидирует payload, а при фатале кладёт сообщение в DLQ с причиной, количеством попыток и метаданными трассировки. Смотрим в тело запроса: без original payload и headers потом нечего дебажить.

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

Минимальный payload для DLQ:
{
"event_id": "abc-123",
"failed_at": "consume",
"reason": "schema_validation_error",
"attempts": 5,
"payload": {...},
"headers": {...}
}
Идемпотентность — это не роскошь, а база: при ручном ре-плейе сообщение должно безопасно пройти повторно. Добавьте dedupe-key, correlation-id и флаг обработки, иначе оператор сам создаст дубликаты быстрее, чем прод.

Храните DLQ отдельно, с TTL, алертами по росту и ручным хендлером для reprocess. Если очередь пухнет — это не “шум”, а сломанный контракт между системами. Ретрай-политика решает всё: временное — в retry, безнадёжное — в DLQ, а потом разбор полётов и фиксация схемы.