Un sistema di ordinazione basato su eventi utilizza una coda standard di Amazon SQS. Durante i test, l'elaborazione si è interrotta perché un singolo messaggio d'ordine ha causato un errore di backend e ha bloccato i messaggi successivi. Il timeout di visibilità della coda è di 30 secondi, mentre l'elaborazione del backend va in timeout dopo 10 secondi. Un architetto di soluzioni deve consentire l'indagine sui messaggi difettosi e assicurarsi che i messaggi successivi continuino a essere elaborati. Cosa dovrebbe fare l'architetto di soluzioni?

L'opzione corretta è creare una coda standard SQS e configurarla come Dead-Letter Queue (DLQ). Questo isola i messaggi che causano errori persistenti, impedendo loro di bloccare l'elaborazione degli altri messaggi. Quando un messaggio fallisce ripetutamente l'elaborazione dopo un certo numero di tentativi (redrive policy), viene spostato nella DLQ, consentendo al sistema di continuare a elaborare i messaggi validi. Aumentare il timeout di elaborazione del backend non risolve il problema del messaggio difettoso; semplicemente ritarda il fallimento. Ridurre il timeout di visibilità di SQS farebbe sì che il messaggio difettoso riapparisse più rapidamente nella coda principale, aggravando il problema. Creare una coda SQS FIFO come DLQ non è necessario in questo scenario, poiché la coda originale è standard e l'ordine dei messaggi non è una priorità stringente per la DLQ.