Uma empresa de e-commerce usa o Amazon SNS para enviar mensagens de pedido a um endpoint HTTPS on-premises que o aplicativo do armazém processa. Algumas mensagens de pedido não foram recebidas. Um arquiteto de soluções deve reter as mensagens não entregues e analisá-las por até 14 dias com o MENOR esforço de desenvolvimento. Qual solução atende a esses requisitos?

A configuração de uma Dead Letter Queue (DLQ) do Amazon SNS com um destino Amazon SQS é a solução mais eficiente. Quando o SNS não consegue entregar uma mensagem ao endpoint HTTPS (por exemplo, devido a erros de rede ou indisponibilidade do servidor), a mensagem é automaticamente enviada para a fila SQS. O SQS pode reter mensagens por até 14 dias, atendendo ao requisito de retenção. Essa abordagem exige o mínimo esforço de desenvolvimento, pois a integração entre SNS e SQS para DLQs é nativa e fácil de configurar. As outras opções são menos ideais: Kinesis Data Stream: Embora possa reter dados por 14 dias, o Kinesis é mais complexo para reter mensagens individuais e não é o serviço padrão para DLQs do SNS. SQS entre o aplicativo e o SNS: Isso alteraria a arquitetura existente e não resolveria o problema de mensagens não entregues pelo SNS ao endpoint. DynamoDB: O DynamoDB é um banco de dados NoSQL e, embora possa usar TTL para retenção, não é o serviço mais adequado para atuar como uma DLQ para mensagens do SNS, exigindo mais lógica de integração e gerenciamento.