Mensageria com SQS na AWS: quando usar e 4 cenários de uso

Uma fila Amazon SQS resolve problemas que mais instâncias e mais banco não resolvem. Aqui estão quatro cenários reais para você reconhecer quando ela entra, do processamento longo ao pico de requisições que derruba o banco.

Depois que aprendi mensageria, ela virou um grande recurso na minha stack para entregar soluções a um cliente. Quem só sabe usar um martelo vê prego em tudo.

O que muda com uma fila no meio

Em vez de a aplicação fazer o trabalho na hora, ela guarda uma mensagem num serviço de mensageria, como o SQS, dizendo que existe um trabalho a fazer. Um serviço em segundo plano consome a mensagem e processa.

A mensagem carrega regras próprias: ela evita que o mesmo trabalho seja processado mais de uma vez e só é apagada quando o trabalho termina. Você ganha garantia de que o trabalho será feito e de que não vai ser repetido, principalmente quando há paralelismo ou multiprocessamento.

Os quatro cenários abaixo mostram isso na prática. Os três primeiros são de uma aula de 2021; o quarto é de uma aula de 2025.

Cenário 1: processamento longo

Imagine que o usuário faz upload de um vídeo de 10 minutos e a aplicação precisa extrair uma imagem a cada 5 segundos. Sem mensageria, o caminho natural é ler o vídeo com uma biblioteca, guardar cada imagem em disco e salvar a referência no banco.

O problema aparece na hora de saber que terminou. Se algo falha no meio do vídeo, como você descobre que o trabalho acabou para avisar o usuário, por e-mail, por exemplo? Você teria que guardar no banco se o vídeo foi processado e montar arranjos técnicos para garantir que todas as imagens foram geradas.

Com mensageria, o fluxo fica assim:

1. Ao receber o vídeo, você guarda a referência no banco como "ainda não processado".
2. Você envia uma mensagem para a fila SQS dizendo que há um trabalho.
3. Um serviço em segundo plano consome a mensagem e faz o processamento.

É uma solução mais elegante e com mais garantias de que o trabalho termina corretamente, sem risco de processar a mesma atividade duas vezes.

Cenário 2: webhook

Outro serviço chama a sua aplicação por webhook e traz um trabalho para processar. O caminho síncrono é retornar 200 e processar na hora. Se o processamento falha, você precisa guardar a informação no banco e ficar tentando de novo.

A alternativa é guardar o que chegou pelo webhook numa mensagem e só depois processar. Enquanto o trabalho não foi processado, a mensagem continua na fila. Além disso, há serviços que ajudam a monitorar essa fila, o que também torna a solução mais elegante.

Cenário 3: exclusão em massa no S3

Esse eu implementei numa plataforma de educação à distância. Os clientes sobem vídeos e, para melhorar a segurança, a entrega e a transcodificação, a plataforma gera chunks desses vídeos. Um vídeo de uma hora vira mais ou menos mil a duas mil partes, guardadas no S3.

Quando um cliente cancela, esse conteúdo precisa ser excluído. De forma síncrona, a aplicação teria um processo rodando até garantir que tudo foi apagado. E aí fica a pergunta: como saber que todas as partes foram excluídas para dar o trabalho como concluído?

O caminho que adotei:

1. Atendido o requisito de saída do cliente, a aplicação manda uma mensagem para o SQS.
2. O SQS envia o evento para uma função Lambda, que faz a exclusão.
3. A Lambda pode trabalhar até o tempo de timeout dela, que no meu caso foi mais que suficiente.

Com um serviço externo, como o Datadog, você ainda acompanha visualmente as filas e vê o que está pendente de processamento.

Cenário 4: pico de requisições sem derrubar o banco

Esse é o cenário da outra aula, Arquitetura na nuvem da AWS com mensageria e SQS, de fevereiro de 2025. Ele mostra por que a fila é também uma questão de custo.

Parta de uma aplicação com uma instância e um banco relacional no RDS. Chegam muitas requisições e você escala: várias instâncias EC2 atrás de um Application Load Balancer. Só que agora todas as instâncias apontam para o mesmo banco, e o elo mais fraco da cadeia passa a ser ele. Se o banco não aguenta o volume, pode haver queda de conexão e o serviço todo sai do ar.

O passo seguinte costuma ser escalar o banco com o Multi-AZ DB Cluster do RDS: várias instâncias respondendo, com um endpoint distribuindo as requisições. Mas normalmente há apenas um endpoint de escrita, e você começa a pagar caro, a ponto de poder inviabilizar o projeto.

Agora imagine que a carga vem de dispositivos, não de usuários, como um serviço que dispara automações em massa: 10 mil requisições chegando ao mesmo tempo. As instâncias podem até dar conta, mas o banco pode não suportar tantas conexões, e aí você acrescenta um proxy na frente dele para gerenciá-las.

Isso traz escala, mas é um jogo que fica cada vez mais caro. O problema não é a sua capacidade de escalar: está na ponta que manda as requisições, porque cada uma bate direto na aplicação. Se o volume brutal pudesse ser processado de forma gradual, a carga inteira não desceria de uma vez no sistema.

A fila entra no meio

O SQS desacopla partes da aplicação. Serve para quem tem parte do sistema on-premises e quer rodar outra parte na nuvem, para rodar uma operação em background ou em batch e para separar partes escritas em linguagens diferentes.

Para os 10 mil pedidos, o desenho fica assim:

1. O Application Load Balancer direciona o tráfego que vem do dispositivo para o API Gateway.
2. O API Gateway só recebe a requisição e a repassa para uma Lambda, escrita na linguagem que você preferir.
3. Essa Lambda só encaminha a mensagem para a fila SQS.
4. Outra Lambda consome a mensagem da fila, de tempos em tempos (por exemplo, pegando uma quantidade de mensagens a cada segundo) ou assim que a mensagem chega.
5. Essa Lambda faz o processamento ou o delega a um Fargate ou a uma instância EC2, em background.

O resultado: a fila recebe as mensagens e o tratamento acontece na sua velocidade. Se o outro sistema mandar 20 mil em vez de 10 mil, elas chegam à fila do mesmo jeito. Você controla como o processamento acontece e pode limitar quantas Lambdas são lançadas (a aula cita um máximo de 5 como exemplo), em vez de lançar tudo de forma descontrolada.

Com o gargalo rompido, você pode voltar a um RDS simples, em vez do Multi-AZ DB Cluster, e reduzir a frota de EC2. Em resumo: custo menor, escala mais previsível e disponibilidade maior, porque parte importante do processamento saiu das instâncias que atendem a aplicação web.

O que estudar depois

Para montar a fila, os conceitos que a aula aponta são: exclusão de mensagem da fila, filas FIFO e Standard, visibility timeout, filas prioritárias e DLQ (a fila de erro).

Checklist

• Procure o trabalho longo que roda dentro da requisição e pergunte como você saberia que ele terminou.
• Troque o processamento síncrono do webhook por uma mensagem guardada na fila.
• Em exclusões ou tarefas em massa, mande uma mensagem para o SQS e consuma com Lambda.
• Se o pico de requisições está derrubando o banco, ponha a fila entre quem envia e a aplicação.
• Limite quantas Lambdas consomem a fila para controlar o ritmo.
• Antes de pagar por Multi-AZ DB Cluster ou proxy, avalie se o desacoplamento com SQS resolve.

Escalar instância e banco funciona, mas fica caro. No desenho da aula, a fila no meio absorveu o pico sem derrubar o sistema e ainda reduziu o custo.