Dead-Letter-Queue

Outcome: Complete the task with Dead-Letter-Queue (Dead-Letter Queue). User context: Importzeile `row-73` schlägt fünfmal fehl, weil ihr Datum fehlerhaft ist. Amazon SQS verschiebt die Nachricht in eine DLQ. Der konfigurierte Alarm des Teams benachrichtigt dann einen Bediener. Nachdem der Parser repariert wurde, leitet der Bediener eine kleine Charge in sicherer Geschwindigkeit erneut. Technical concept or control: Dead-Letter-Queue (Dead-Letter Queue). Why it fits: Verwenden Sie eine DLQ, wenn wiederholte Fehler das erneute Durchlaufen der Hauptwarteschlange stoppen sollten. Bewahren Sie Grund, Quelle, Versuchszähler, Nachrichtenalter und einen sicheren Rückleitungsweg auf. Do not use it when: Verschiebe eine Nachricht nach dem ersten kurzen Fehler nicht, ignoriere eine wachsende DLQ nicht, und führe kein Redrive aus, bevor die Ursache behoben ist. Das Entfernen eines Elements kann auch einen Ablauf unterbrechen, der eine strikte Reihenfolge erfordert. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Kein einziger offizieller Standard kontrolliert den gesamten Begriff. Seine Bedeutung kann sich zwischen Teams, Plattformen oder Frameworks ändern. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.