Una solución de datos meteorológicos recibe telemetría de miles de estaciones a través de una API REST de API Gateway integrada con una función Lambda. La función Lambda llama a un servicio de terceros para el preprocesamiento; cuando ese tercero se sobrecarga, el preprocesamiento falla y se pierden datos. El arquitecto debe asegurarse de que no se pierdan datos y permitir que el procesamiento se realice más tarde si ocurren fallas. ¿Qué debería implementar el arquitecto?

La opción correcta garantiza la durabilidad de los datos y el procesamiento asíncrono. Al enviar los datos directamente a una cola SQS, se desacopla la API Gateway de la función Lambda y del servicio de terceros, evitando la pérdida de datos si el preprocesamiento falla. La función Lambda se invoca desde la cola principal, y si el procesamiento falla (por ejemplo, debido a la sobrecarga del servicio de terceros), el mensaje se reintenta y, eventualmente, se mueve a la DLQ (cola secundaria) si los reintentos fallan. Esto permite el procesamiento posterior sin perder los datos originales. Las opciones incorrectas no abordan completamente el problema: Usar SQS como DLQ para la API no resuelve el problema de la pérdida de datos si la invocación inicial de Lambda falla antes de que el mensaje llegue a SQS. EventBridge no es la mejor solución aquí porque su propósito principal es el enrutamiento de eventos, no la persistencia de mensajes para reintentos en caso de fallas de procesamiento prolongadas como SQS. Configurar un bus de eventos como destino de fallas de Lambda solo captura los eventos que fallan en la invocación de Lambda, no los que fallan en el servicio de terceros.