Un'azienda gestisce un servizio di consegna di cibo. A causa della recente crescita, il sistema di elaborazione degli ordini dell'azienda sta riscontrando problemi di scalabilità durante le ore di punta del traffico. L'architettura attuale include istanze Amazon EC2 in un gruppo Auto Scaling che raccolgono gli ordini da un'applicazione. Un secondo gruppo di istanze EC2 in un gruppo Auto Scaling evade gli ordini. Il processo di raccolta degli ordini avviene rapidamente, ma il processo di evasione degli ordini può richiedere più tempo. I dati non devono essere persi a causa di un evento di scalabilità. Un architetto di soluzioni deve garantire che sia il processo di raccolta degli ordini che il processo di evasione degli ordini possano scalare adeguatamente durante le ore di punta del traffico. Quale soluzione soddisferà questi requisiti?

La soluzione corretta prevede l'utilizzo di due code Amazon SQS, una per la raccolta degli ordini e una per l'evasione. Le istanze EC2 effettueranno il polling delle rispettive code e i gruppi Auto Scaling verranno scalati in base al numero di messaggi in ciascuna coda. Questo disaccoppia i processi di raccolta e evasione, permettendo loro di scalare indipendentemente in base al carico effettivo. SQS garantisce che nessun dato venga perso, anche durante i picchi di traffico, poiché i messaggi rimangono nella coda finché non vengono elaborati. Le altre opzioni sono meno efficaci: Scalare solo in base alla CPUUtilization potrebbe non essere sufficiente se il collo di bottiglia è altrove o se il tempo di elaborazione varia. Impostare la capacità minima al carico di picco è inefficiente e costoso. Creare gruppi Auto Scaling aggiuntivi su richiesta tramite SNS non è la soluzione più efficiente per la scalabilità dinamica basata sul carico di lavoro. Scalare i gruppi Auto Scaling in base alle "notifiche inviate dalle code" è meno preciso rispetto allo scalare direttamente in base al numero di messaggi nella coda, che è una metrica diretta del backlog di lavoro.