A API de uma empresa recebe dados em tempo real de dispositivos de monitoramento e os armazena em uma instância de banco de dados Amazon RDS. O volume de dados de entrada flutua e, durante tráfego intenso, a API atinge o tempo limite porque o banco de dados não consegue processar o volume de gravação. Um arquiteto de soluções deve minimizar as conexões com o banco de dados e garantir que não haja perda de dados durante tráfego intenso. Qual solução atende a esses requisitos?

A solução correta é modificar a API para gravar os dados em uma fila do Amazon SQS e usar uma função AWS Lambda para processar esses dados e gravá-los no banco de dados. Isso desacopla a API do banco de dados, permitindo que a API responda rapidamente e que o SQS absorva picos de tráfego, garantindo que nenhum dado seja perdido. A função Lambda pode ser configurada para escalar automaticamente, processando os itens da fila em um ritmo que o banco de dados possa suportar, minimizando as conexões diretas e o risco de timeouts. Aumentar o tamanho da instância pode ajudar, mas não resolve o problema de picos de tráfego e não desacopla a API do banco de dados. Uma instância Multi-AZ melhora a disponibilidade e a resiliência, mas não o desempenho de gravação para um único endpoint e não é projetada para o aplicativo gravar em todas as instâncias ativas simultaneamente para escalabilidade de escrita. Usar o SNS para este caso não é ideal porque o SNS é um serviço de publicação/assinatura, não uma fila de mensagens para desacoplamento e processamento assíncrono de dados neste cenário.