Un'applicazione per l'ordinazione al dettaglio utilizza attualmente un parco istanze EC2 con bilanciamento del carico per l'hosting web, i servizi API di database e la logica di business. L'azienda desidera eseguire il refactoring verso un'architettura disaccoppiata e scalabile che mantenga gli ordini falliti per l'elaborazione successiva, riducendo al minimo l'overhead operativo. Quale architettura soddisfa al meglio questi obiettivi?

L'opzione corretta soddisfa tutti i requisiti. Ospitare il sito web su Amazon S3 è un approccio comune e scalabile per i contenuti statici. AWS AppSync è ideale per le API di database, offrendo funzionalità in tempo reale e offline. Amazon SQS fornisce una coda di messaggi completamente gestita e scalabile per gli ordini, e AWS Lambda è perfetto per la logica di business serverless, riducendo l'overhead operativo. L'uso di una coda dead-letter (DLQ) di SQS è la soluzione nativa e più efficiente per conservare gli ordini falliti per l'elaborazione successiva, senza costi aggiuntivi di gestione. Le altre opzioni presentano delle criticità: La prima opzione usa ECS per la logica di business, che ha un overhead operativo maggiore rispetto a Lambda, e si affida al long polling di SQS per mantenere gli ordini falliti, il che non è il meccanismo standard per la conservazione degli errori. La seconda opzione usa Amazon MQ, che è meno scalabile e più costoso di SQS per questo caso d'uso, e S3 Glacier Deep Archive non è adatto per la conservazione di ordini falliti che richiedono un'elaborazione successiva tempestiva. La quarta opzione usa Amazon Lightsail, meno adatto per architetture disaccoppiate e scalabili, e Amazon SES (Simple Email Service) non è una coda di messaggi per gli ordini. Amazon OpenSearch Service non è il servizio appropriato per mantenere gli ordini falliti in attesa di rielaborazione.