Dead-letter queue

Dead-letter queue - a side channel where a pipeline parks messages it cannot process, the dead letter queue streaming systems use so one malformed message does not stop the other million. The mechanism is mostly policy: when a message fails parsing or processing, after whatever retries you allow, write it to a separate topic with enough context to diagnose it later (original payload, error, offset, timestamp), then move on. The alternative is the poison-pill loop: the consumer reads the message, crashes, restarts, reads the same message. A pipeline can spend a whole weekend doing that.

The underused half is the second act. A DLQ nobody reads is a slow delete queue; the point is to inspect the parked messages, fix the cause, and replay them.

Do you need it? If your input comes from anything you do not control, yes. It is one extra topic and an error branch, cheap insurance against at-least-once redelivering the same poison forever. The pattern owes nothing to cluster machinery either: it works the same when the consumer is a single binary, and ubik's run stats report dropped rows as a count on stderr rather than a silence, so you at least know when you need one.