Una empresa opera un servicio de entrega de alimentos. Debido al crecimiento reciente, el sistema de procesamiento de pedidos de la empresa está experimentando problemas de escalado durante las horas pico de tráfico. La arquitectura actual incluye instancias de Amazon EC2 en un grupo de Auto Scaling que recopilan pedidos de una aplicación. Un segundo grupo de instancias EC2 en un grupo de Auto Scaling cumple los pedidos. El proceso de recopilación de pedidos ocurre rápidamente, pero el proceso de cumplimiento de pedidos puede tardar más. Los datos no deben perderse debido a un evento de escalado. Un arquitecto de soluciones debe asegurarse de que el proceso de recopilación de pedidos y el proceso de cumplimiento de pedidos puedan escalar adecuadamente durante las horas pico de tráfico. ¿Qué solución cumplirá estos requisitos?

La opción correcta es la que propone usar dos colas de Amazon SQS y escalar los grupos de Auto Scaling basándose en el número de mensajes en cada cola. Esto desacopla los procesos de recopilación y cumplimiento de pedidos, permitiendo que cada uno escale de forma independiente según su carga de trabajo. SQS actúa como un búfer, garantizando que los pedidos no se pierdan durante picos de tráfico y que las instancias de cumplimiento puedan procesarlos a su propio ritmo. Escalar en función del número de mensajes en la cola es una métrica directa de la demanda, lo que asegura una escalabilidad eficiente. Las otras opciones son incorrectas porque: Monitorear solo la CPUUtilization y configurar la capacidad mínima a la carga máxima es ineficiente y no reactivo a los cambios dinámicos de la demanda. Invocar un tema de SNS para crear grupos de Auto Scaling adicionales bajo demanda no es una estrategia de escalado automático basada en la carga de trabajo y es demasiado manual. Escalar los grupos de Auto Scaling en función de "notificaciones que envían las colas" es vago y no especifica una métrica clara para el escalado, a diferencia de la métrica de "número de mensajes".