Kolejka błędów (dead letter queue, DLQ)

Kolejka błędów, nazywana dead letter queue albo DLQ, przechowuje zadania, których główna kolejka lub workflow nie zdołały poprawnie obsłużyć. Zadanie trafia tam zwykle po przekroczeniu limitu ponowień, na przykład gdy API CRM zwraca błąd, dane formularza są niepoprawne albo usługa docelowa jest niedostępna. Dzięki temu nie znika z historii bez śladu.

W automatyzacji biznesowej jest to różnica między „nie wiemy, co stało się z leadem” a listą konkretnych przypadków do sprawdzenia. DLQ powinna zachować oryginalny ładunek danych, identyfikator zdarzenia, czas błędu, liczbę prób i możliwie bezpieczny opis przyczyny. Taki zapis pozwala odróżnić problem jednego rekordu od awarii całej integracji.

Przykład: formularz na stronie wysyła webhook do systemu, który tworzy kontakt w CRM i dopisuje tag kampanii. Jeśli CRM odrzuci rekord przez błędny format telefonu, automatyzacja nie powinna bez końca próbować tego samego zapisu. Po kilku kontrolowanych próbach przenosi zdarzenie do DLQ i tworzy zadanie do ręcznej korekty. Po poprawce można przetworzyć tylko ten jeden przypadek.

DLQ nie jest zwykłym logiem błędów. Log mówi, że coś się wydarzyło. Kolejka błędów zachowuje pracę do odzyskania i zwykle ma własny proces obsługi. W małej firmie może to być tabela z alertem i przyciskiem „ponów po korekcie”. W większym systemie będzie to osobna kolejka, monitoring i procedura eskalacji.

Projektuj ją razem z ponowieniami i idempotencją. Ponowienie ma sens przy błędach tymczasowych, takich jak limit API lub chwilowa niedostępność. Nie ma sensu przy błędzie walidacji, który wymaga zmiany danych. Idempotencja chroni przed utworzeniem duplikatu, gdy zadanie zostanie wznowione po tym, jak poprzednia próba częściowo zadziałała.

Najczęstszy błąd to potraktowanie DLQ jako szuflady bez właściciela. Jeśli nikt jej nie przegląda, system nadal traci sprawy, tylko wolniej i bardziej elegancko. Ustal osobę, częstotliwość przeglądu, czas przechowywania danych oraz regułę: które błędy naprawiasz, które odrzucasz i kiedy uruchamiasz proces ponownie.

Zacznij od jednego krytycznego przepływu, na przykład lead z formularza do CRM. Dodaj identyfikator zdarzenia, maksymalnie trzy próby z odstępem, miejsce dla nieudanych rekordów i alert, gdy pojawi się pierwszy wpis. Dopiero potem dodawaj bardziej złożone automatyczne naprawy. Celem nie jest zero błędów, lecz brak cichych strat danych.