Це запитання часто звучить на backend або full-stack інтервʼю, особливо на проєкти з розподіленими системами. Кожна конкретна технологія(SQS, RabbitMQ, Kafka…), має свої підходи до Dead Letter Queue(DLQ) тому краще зосередитись на розумінні того, як це працює і які проблеми вирішує.
З точки зору системного дизайну, це патерн в message-driven архітектурі, який ізолює невдалі повідомлення в окрему чергу. Це дозволяє не блокувати основний потік, не втрачати дані і дати можливість знайти причину помилки та повторно відпрацювати повідомлення.
Важливо розуміти, що DLQ не вирішує корінь проблеми, по якій стався збій. Його задача в тому щоб контрольовано зберегти невдалі повідомлення, проаналізувати їх і прийняти рішення про подальшу обробку таких повідомлень.
Розберемо приклад
У нас є мікросервіс Payments, який після успішного платежу публікує подію: PaymentSucceeded { paymentId, userId, planId, amount, occurredAt }. Інший мікросервіс Subscriptions, слухає її і після отримання створює підписку в базі даних і надсилає welcome email через сторонній провайдер.
Найпростіший сценарій де буде корисний DLQ це відмова стороннього API, яке займається відправкою емейлів. Після того, як отримуємо 502 помилку з third party сервісу, ми пробуємо ще 3 рази з інтервалом в 30 секунд(retry + backoff). Якщо ми і далі отримуємо 502, відправляємо повідомлення в DLQ. Після того як провайдер відновився, ми пробуємо обробити ці повідомлення повторно - це називається DLQ re-drive.