Uma empresa usa rastreadores GPS para documentar padrões de migração de milhares de tartarugas marinhas. Os rastreadores verificam a cada 5 minutos e, se uma tartaruga se moveu mais de 91,4 metros (100 jardas), eles enviam novas coordenadas para um aplicativo web executado em três instâncias Amazon EC2 em várias Availability Zones em uma AWS Region. Recentemente, o aplicativo web foi sobrecarregado por um volume inesperado de dados do rastreador, e os dados foram perdidos sem nenhuma maneira de reproduzir os eventos. Um arquiteto de soluções deve evitar que isso aconteça novamente com o menor overhead operacional. O que o arquiteto de soluções deve fazer?

A criação de uma fila do Amazon SQS desacopla o produtor (rastreadores GPS) do consumidor (aplicativo web), garantindo que os dados não sejam perdidos mesmo que o aplicativo esteja sobrecarregado. O SQS armazena as mensagens de forma durável e o aplicativo pode processá-las em seu próprio ritmo, pesquisando a fila. Isso minimiza o overhead operacional, pois o SQS é um serviço totalmente gerenciado. As outras opções são menos adequadas: Um bucket S3 não é ideal para receber fluxos contínuos de pequenos dados que precisam ser processados imediatamente por um aplicativo. O aplicativo teria que verificar o bucket constantemente, o que não é eficiente. O API Gateway com Lambda pode ser uma solução, mas o Lambda processa cada item simultaneamente, o que pode sobrecarregar o aplicativo downstream se o volume for muito alto, e não oferece a durabilidade de mensagens do SQS para dados não processados. O DynamoDB é um banco de dados, não uma fila de mensagens. Embora possa armazenar dados, o aplicativo teria que consultar a tabela constantemente para novos dados, o que é ineficiente e não resolve o problema de sobrecarga do consumidor de forma assíncrona como o SQS. O TTL é para remoção de dados, não para gerenciamento de fluxo.