← BACK TO DRAWING SET
SPECIFICATION · CONCEPT BRIEFDWG · 13-LETTERS-THAT-WOULDNT-SEND

Letters that Wouldn't Send

Don't drop poison messages on the floor — keep them for later.

§01The problem with silent drops

When a queue overflows, the simplest behavior is to drop new arrivals. But silent drops are a debugging nightmare: you can't see what was lost, can't replay it, and may not even know it happened.

§02What a DLQ does

A dead-letter queue is a side-channel for messages that couldn't be processed. Overflows, poison pills, repeated failures — they all land here instead of being lost. Operators inspect, fix, and replay them.

In Flow, draw an edge from a queue to a target node, click the edge, and tick "Dead-letter queue". When the queue overflows, those messages land at the DLQ target instead of vanishing.

NOTE
DLQ is observability
Even if you never replay anything from the DLQ, having it means you can answer 'how much did we drop and why?' — which beats 'I don't know' every time.
⚑ CHEATSHEET · QUICK REFERENCE
  • Mark a queue's overflow edge as DLQ to keep failed messages.
  • DLQ depth is a key alert signal — a growing DLQ means something is broken upstream.
▸ THE EXERCISE

Heavy write load to a slow consumer overflows the queue and you can't tell what was lost. Wire a dead-letter queue from the queue's overflow path to a database for later inspection.

▸ START EXERCISEBACK TO DRAWING SET