Un'azienda sta progettando un'applicazione web su AWS per elaborare preventivi assicurativi. Gli utenti richiedono preventivi. I preventivi devono essere separati per tipo, devono ricevere una risposta entro 24 ore e non devono essere persi. La soluzione dovrebbe massimizzare l'efficienza operativa e minimizzare la manutenzione. Quale soluzione soddisfa questi requisiti?

La soluzione corretta utilizza Amazon SNS e SQS con il filtraggio dei messaggi. Un singolo argomento SNS riduce la complessità di gestione rispetto a più argomenti. Le code SQS garantiscono che i preventivi non vengano persi (durabilità) e che possano essere elaborati entro 24 ore (decoupling asincrono). Il filtraggio dei messaggi SNS instrada i preventivi alla coda SQS appropriata in base al tipo, soddisfacendo il requisito di separazione. Questa architettura massimizza l'efficienza operativa e minimizza la manutenzione grazie alla natura serverless e gestita di SNS e SQS. Le altre opzioni sono meno efficienti o non soddisfano tutti i requisiti: Kinesis Data Streams richiede una gestione più attiva dei consumatori (KCL) e non è l'ideale per un modello di elaborazione asincrona basato su messaggi con garanzia di consegna come SQS. L'uso di una funzione Lambda e un argomento SNS per ogni tipo di preventivo aumenterebbe la complessità e la manutenzione per ogni nuovo tipo di preventivo, oltre a non offrire la durabilità intrinseca di SQS per i messaggi non elaborati. Kinesis Data Firehose e Amazon OpenSearch Service sono più adatti per l'analisi e la ricerca di log o dati in tempo reale, non per la gestione di code di messaggi per l'elaborazione asincrona di richieste.