Eventual Retry / Poison Message Handling

Problem

A message fails because the database is temporarily unavailable. Retrying makes sense. Another message fails because its data is permanently invalid. Retrying it 50,000 times does not.

Solution — Retry Policy + DLQ

Classify failures and bound retries.

Transient → retry
Permanent → DLQ

Core idea: resilient messaging distinguishes failures that may recover from messages that require intervention.