Асинхронная обработка обычно предполагает, что ошибка временна. Не получилось сейчас — попробуем позже. Это отлично работает при кратком сбое базы, сети или внешнего API.
Но часть ошибок не исчезнет после десятого повтора. В сообщении может быть некорректный формат, недостающие данные, неизвестный тип события или бизнес-состояние, которое обработчик уже не понимает.
Какую проблему мы решаем
Если такое сообщение постоянно возвращать в основную очередь, оно потребляет ресурсы, создаёт шум и в некоторых системах способно тормозить обработку следующих сообщений.
После ограниченного числа неудачных попыток сообщение отправляется в отдельную Dead Letter Queue — очередь сообщений, которые обычный поток не смог обработать.
Основной consumer продолжает работу, а проблемный объект сохраняется вместе с контекстом ошибки. Команда может исследовать причину, исправить данные или код и затем повторно отправить сообщение на обработку.
Что получает бизнес
Главная выгода — единичная ошибка реже превращается в остановку целого бизнес-процесса.
Если один заказ, документ или интеграционное событие некорректны, остальные тысячи операций не обязаны ждать, пока команда разберётся именно с этим случаем.
Одновременно компания не теряет проблемную операцию бесследно. Её можно найти, классифицировать и восстановить. Для процессов, где потеря события означает деньги, обязательства или ручную работу, это важнее красивой статистики успешной обработки.
Но DLQ имеет ценность только при наличии владельца и процесса разбора. Очередь, которую никто не смотрит, — это просто аккуратное место для накопления потерянного бизнеса.
Что получает команда
Команда получает разделение временных и постоянных ошибок. Retry занимается первым типом, DLQ — вторым.
Становится проще анализировать повторяющиеся классы ошибок, видеть несовместимые версии сообщений и находить реальные дефекты данных.
После устранения причины накопившиеся сообщения можно возвращать в обработку контролируемо, а не восстанавливать вручную из логов.
Что получает клиент
Клиент получает меньше ситуаций, когда одна чужая проблемная операция тормозит общий поток.
При этом его собственная неуспешная операция может завершиться не сразу. Поэтому продукту нужен статус, повторная обработка или понятный путь поддержки, а не тихое исчезновение сообщения в технической очереди.
Чем мы за это платим
Появляется ещё одна очередь, правила хранения, алерты и инструменты повторной обработки.
Нужно решить, сколько retry делать до DLQ, какие ошибки считать временными и как избежать повторного выполнения уже частично завершённой операции.
Самая опасная цена — операционная привычка игнорировать DLQ. Если сообщения копятся неделями, система выглядит здоровой только потому, что проблемы вынесены за пределы основного графика.
Когда DLQ не нужна
Если обработка полностью синхронная или ошибка всегда немедленно возвращается вызывающей стороне, отдельная dead-letter очередь может не понадобиться.
Она также бессмысленна без возможности восстановить или исследовать сообщение. Если политика бизнеса прямо говорит, что неуспешный объект можно безопасно отбросить, достаточно корректного логирования и метрик.
Что стоит спросить перед решением
- Какие ошибки действительно исправятся после retry, а какие нет?
- Сколько попыток допустимо до изоляции сообщения?
- Кто владеет DLQ и как быстро обязан разбирать накопление?
- Можно ли безопасно повторно выполнить операцию после исправления?
- Как клиент или бизнес узнает, что его операция застряла?
В итоге
Dead Letter Queue — это не корзина для всего, что не получилось. Это отдельный процесс для исключений.
Для бизнеса она полезна тогда, когда плохая операция перестаёт блокировать хорошие, но при этом остаётся видимой и восстанавливаемой.