DLQ — не мусорка: как не потерять упавшие события и не сломать пайплайн

DLQ — не мусорка: как не потерять упавшие события и не сломать пайплайн

Dead Letter Queue нужна не для «потом посмотрим», а для изоляции ядовитой полезной нагрузки. Если хендлер не смог распарсить JSON, не прошёл валидацию или внешний API вернул 4xx/5xx после ретраев — событие уезжает в DLQ с причиной, исходным payload и метаданными: source, attempt_count, first_seen_at, trace_id.

Минимальная схема: основной consumer кладёт событие в бизнес-очередь, воркер обрабатывает, при исчерпании ретраев пишет в DLQ. В DLQ должен быть отдельный consumer для ручного или автоматического reprocess. Не смешивайте его с основной очередью: иначе один битый формат начнёт тормозить всё. Идемпотентность — это не роскошь, а база: при повторной отправке используйте event_id или hash полезной нагрузки.

Храните причину падения явно, а не в логах где-то рядом. Полезно фиксировать:
• original_payload
• error_class
• retry_count
• failed_at
• handler_name

Для PostgreSQL это может быть таблица с JSONB и индексом по status, для брокера — отдельный топик/очередь с TTL. Для Nginx/ingress и сетевых сбоев DLQ тоже полезна: 502 и таймауты не должны теряться в пустоте.

Главное правило: у DLQ должен быть процесс разбора, а не культ накопления. Без регулярного reprocess и очистки вы просто переносите аварию из продакшена в склад проблем.