Una empresa de comercio electrónico utiliza Amazon SNS para enviar mensajes de pedidos a un endpoint HTTPS on-premises que procesa la aplicación del almacén. Algunos mensajes de pedidos no se recibieron. Un arquitecto de soluciones debe retener los mensajes no entregados y analizarlos durante un máximo de 14 días con el MÍNIMO esfuerzo de desarrollo. ¿Qué solución cumple estos requisitos?

La opción correcta es configurar una cola de mensajes fallidos (Dead-Letter Queue, DLQ) de Amazon SNS que use Amazon SQS como destino con un período de retención de 14 días. Cuando los mensajes no se entregan a un endpoint HTTPS (por ejemplo, debido a errores de red o de aplicación), SNS los reenvía automáticamente a la DLQ. SQS retendrá estos mensajes hasta por 14 días, lo que permite su posterior análisis y reprocesamiento con un esfuerzo de desarrollo mínimo. Las otras opciones son incorrectas: Kinesis Data Stream no es un destino directo para una DLQ de SNS y su uso requeriría más desarrollo para manejar los mensajes fallidos. Intercalar SQS entre la aplicación y SNS no es el flujo estándar para manejar mensajes no entregados por SNS; la DLQ de SNS está diseñada para este propósito. DynamoDB con TTL podría almacenar los mensajes, pero no es el mecanismo nativo de SNS para manejar mensajes fallidos y requeriría una integración más compleja que una DLQ de SQS.