Una empresa tiene un flujo de trabajo de ingesta de datos que consiste en un tema de Amazon SNS que recibe notificaciones sobre nuevas entregas de datos y una función de AWS Lambda que procesa y almacena los datos. Ocasionalmente, la ingesta falla debido a problemas de conectividad de red, y esos datos no se ingieren a menos que se vuelva a ejecutar un trabajo manualmente. ¿Qué debe hacer un arquitecto de soluciones para garantizar que todas las notificaciones se procesen finalmente?

La opción correcta es configurar una cola de Amazon SQS como destino en caso de fallo y modificar la función Lambda para procesar los mensajes de la cola. Esto crea un mecanismo de "Dead-Letter Queue" (DLQ) para la función Lambda. Cuando la función Lambda falla (por ejemplo, debido a problemas de conectividad), los mensajes fallidos se envían a la cola SQS. La función Lambda puede entonces configurarse para procesar estos mensajes de la DLQ, asegurando que los datos se reintenten y finalmente se ingieran, incluso después de fallos iniciales. Las otras opciones son incorrectas: Configurar la función Lambda para su implementación en varias zonas de disponibilidad mejora la disponibilidad, pero no resuelve el problema de reintentar mensajes fallidos debido a problemas transitorios de red. Aumentar las asignaciones de CPU y memoria podría mejorar el rendimiento y reducir algunos tipos de fallos, pero no proporciona un mecanismo de reintento automático para fallos de red persistentes o transitorios. Configurar la estrategia de reintentos del tema de SNS solo afecta los reintentos de entrega de SNS a sus suscriptores, no los reintentos de la función Lambda una vez que ha recibido el evento y ha fallado en su procesamiento interno.