Uma solução de dados meteorológicos recebe telemetria de milhares de estações por meio de uma API REST do API Gateway integrada a uma função Lambda. O Lambda chama um serviço de terceiros para pré-processamento; quando esse terceiro fica sobrecarregado, o pré-processamento falha e os dados são perdidos. O arquiteto deve garantir que nenhum dado seja perdido e permitir que o processamento ocorra posteriormente se falhas acontecerem. O que o arquiteto deve implementar?

A solução correta utiliza o Amazon SQS para desacoplar a API Gateway/Lambda do serviço de terceiros, garantindo que nenhum dado seja perdido. Ao enviar as mensagens para uma fila SQS primária, a API Gateway não precisa esperar pela resposta do serviço de terceiros. Uma função Lambda separada pode então consumir mensagens dessa fila e tentar o pré-processamento. Se o pré-processamento falhar devido à sobrecarga do serviço de terceiros, a mensagem pode ser reprocessada posteriormente ou movida para uma fila SQS secundária (DLQ) para análise e reprocessamento manual, evitando a perda de dados. As outras opções são incorretas porque: Criar uma DLQ para a API não resolve o problema de sobrecarga do serviço de terceiros e a perda de dados durante o pré-processamento. A DLQ da API seria para falhas na própria API, não no processamento posterior. Usar o Amazon EventBridge não é a solução ideal para desacoplamento e reprocessamento de mensagens neste cenário. Embora o EventBridge possa rotear eventos, ele não oferece o mesmo mecanismo de fila e reprocessamento garantido que o SQS para lidar com falhas transitórias de serviços externos. Configurar um barramento de eventos secundário como destino de falha do Lambda ainda não garante o reprocessamento automático e persistente que o SQS oferece.