Un'azienda ha un'applicazione legacy per l'elaborazione dei dati che viene eseguita su istanze Amazon EC2. I dati vengono elaborati in sequenza, ma l'ordine dei risultati non è importante. L'applicazione utilizza un'architettura monolitica e attualmente scala solo aumentando la dimensione dell'istanza. Gli sviluppatori stanno riscrivendo l'applicazione come microservizi su Amazon Elastic Container Service (Amazon ECS). Cosa dovrebbe consigliare un architetto di soluzioni per la comunicazione tra i microservizi?

La risposta corretta è creare una coda Amazon SQS. SQS è un servizio di accodamento di messaggi completamente gestito che consente la comunicazione asincrona e disaccoppiata tra i microservizi. Poiché l'ordine dei risultati non è importante e l'applicazione elabora i dati in sequenza, SQS è ideale per gestire il carico di lavoro, consentendo ai produttori di inviare messaggi e ai consumatori di elaborarli in modo indipendente e scalabile. Le altre opzioni sono meno adatte: Amazon SNS è un servizio di pubblicazione/sottoscrizione che invia notifiche a più sottoscrittori contemporaneamente. Non è l'ideale per l'elaborazione sequenziale di dati da parte di un gruppo di consumatori. L'utilizzo di AWS Lambda per passare messaggi introdurrebbe un punto di fallimento centrale e complessità non necessarie, oltre a non fornire un meccanismo di accodamento robusto. DynamoDB Streams è progettato per catturare modifiche a una tabella DynamoDB, non per la comunicazione diretta tra microservizi in questo contesto. Sebbene possa essere usato per notificare modifiche, non è il servizio primario per l'accodamento di messaggi.