DLQ не свалка: как хранить упавшие события так, чтобы их можно было разгрести

DLQ не свалка: как хранить упавшие события так, чтобы их можно было разгрести

Dead Letter Queue нужна не для «потом посмотрим», а для изоляции ядовитых сообщений. Если хендлер не может распарсить payload, не проходит валидацию или внешний API отвечает 4xx без шансов на успех — событие надо увести из основной очереди, иначе ретраи положат весь пайплайн.

Базовая схема: основной consumer получает сообщение, пишет state, делает обработку и только потом ACK. Если ошибка не transient — публикуем в DLQ вместе с метаданными: original_topic, partition, offset, retry_count, error_class, trace_id, received_at. Без этого DLQ превращается в кладбище без табличек.

Храните в DLQ не только тело запроса, но и контекст. Минимум:
- сырой JSON payload;
- заголовки и подпись;
- причину падения;
- версию схемы;
- ключ идемпотентности.
Смотрим в тело запроса и отдельно проверяем, не сломали ли нас кривые поля, пустые строки и дубль события.

Реанимация должна быть отдельным процессом: ручной requeue после фикса бага, автоматический replay только после дедупликации и rate-limit. Идемпотентность — это не роскошь, а база: если повторный запуск создаёт дубль в CRM, DLQ вам не поможет, он просто отложит катастрофу.

Вывод простой: DLQ проектируют как forensic-зону, а не мусорку. Если у события нет метаданных, политики ретраев и понятного пути возврата в очередь, вы не дебажите инцидент — вы коллекционируете его.