Una función Lambda de procesamiento de pedidos consume mensajes de una cola de Amazon SQS y escribe los resultados en una tabla de DynamoDB. La función Lambda se ejecuta con concurrencia reservada. Los clientes informan que la página del historial de pedidos se retrasa en mostrar el estado del procesamiento. ¿Qué acciones debería tomar un ingeniero de DevOps para diagnosticar y corregir la latencia? (Elija dos)

La latencia en el procesamiento de pedidos puede deberse a cuellos de botella en SQS o DynamoDB. La métrica ApproximateAgeOfOldestMessage de SQS indica cuánto tiempo ha estado esperando el mensaje más antiguo en la cola. Un valor alto sugiere que la función Lambda no está procesando mensajes lo suficientemente rápido. Aumentar la concurrencia reservada de Lambda permite que se ejecuten más instancias simultáneamente, procesando la cola más rápido. Por otro lado, DynamoDB WriteThrottleEvents indica que DynamoDB está rechazando solicitudes de escritura debido a la falta de capacidad. Aumentar las unidades de capacidad de escritura (WCUs) máximas en la política de autoescalado de la tabla permite que DynamoDB maneje más escrituras, eliminando este cuello de botella. Las otras opciones son incorrectas porque: Configurar una política de reintento (redrive policy) en SQS no resuelve la latencia, solo gestiona mensajes fallidos. NumberOfMessagesSent solo muestra cuántos mensajes se enviaron, no si se procesaron a tiempo. Aumentar el tiempo de espera de visibilidad de SQS podría retener los mensajes por más tiempo, empeorando la latencia. Lambda Throttles indica que la función está siendo limitada, pero aumentar el tiempo de espera de la función no resuelve el problema de la limitación o la capacidad de procesamiento.