What happens to the records an AI integration cannot process?
They should land in a dead letter queue: a holding area for events that failed after their retries, stored with the original payload and the error. The point is that failures stay visible and replayable instead of vanishing. A system with no dead letter queue is not failure-free, it is failure-blind, and the missing records usually resurface weeks later as an unexplained gap in a report.
Three possible fates for a failed event
Every integration handles failure somehow, even if nobody chose the behavior deliberately.
- Dropped silently. The exception is caught, logged at debug level, and forgotten. This is the default in a surprising amount of software.
- Retried forever. The item never succeeds and never leaves, consuming quota and crowding out healthy work.
- Parked with context. After a bounded number of attempts it moves to a dead letter queue with the payload, the error, the attempt count and the timestamps. Only this option lets you recover.
What has to be stored alongside the failure
A queue of bare error messages is nearly useless. To replay an item you need the original input exactly as received, the identifiers linking it to the source system, the version of the code and prompt that processed it, and the full error rather than a truncated summary.
Store the input, not a transformed version of it. Half the value of a dead letter queue is being able to fix the transform and rerun the original, which is the same replayability that makes integration work recoverable in general.
Reading the queue tells you what is actually wrong
Do not read it item by item. Cluster it by error type and by source. One account with malformed data produces a tight cluster around one identifier. A vendor field change produces a cluster that starts abruptly on a specific date. A capacity problem produces timeouts spread evenly across everything.
The distribution is the diagnostic. A dead letter queue that suddenly fills from a single hour is telling you about an outage; one that fills slowly across weeks is telling you about a data quality problem nobody has owned.
The queue needs an owner and a target
Unowned queues grow until they are unusable, at which point somebody purges them and the information is gone. Give it a named owner, a review cadence, and an explicit expectation for depth, so that "the queue is above its target" is a condition somebody responds to rather than a permanent state of affairs.
If nobody will own it, the honest move is to alert on the failure directly rather than pretending a queue nobody reads counts as handling. That kind of tradeoff is normal in operational systems and it is better decided out loud.
Topics: dead letter queue · error handling · reliability · data quality
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.