Dead Letter Queue: последний рубеж перед потерей данных

Dead Letter Queue: последний рубеж перед потерей данных

DLQ — это не мусорный ящик. Это журнал событий которые система не смогла обработать и которые требуют внимания.

Типичная архитектура: основная очередь → обработчик → при N неудачных попытках → DLQ. Само по себе попадание в DLQ не страшно. Страшно когда DLQ никто не мониторит и там тихо накапливаются события.

Что должно быть в DLQ-записи:
- Оригинальное тело хука
- Все заголовки (нужны для повторной обработки)
- Timestamp первой и последней попытки
- Причина последней ошибки (stacktrace или код ответа)
- Количество попыток

Процесс работы с DLQ: алерт при появлении первого сообщения, ротация дежурного, обязательный разбор в течение 4 часов для финансовых событий.

Переобработка: не запускай массово «всё что в DLQ» — сначала исправь причину падения, потом обрабатывай по одному или небольшими батчами с мониторингом.

Инструменты: AWS SQS DLQ, RabbitMQ dead-letter-exchange, Kafka dead letter topic. Для простых случаев — отдельная таблица в БД с индексом по статусу.