Filas e mensageria
RabbitMQ, Kafka e o que muda entre uma fila de tarefas e um log de eventos.
Esperar ou não esperar
Quando um cliente finaliza uma compra, várias coisas precisam acontecer: registrar o pedido, cobrar, baixar o estoque, enviar o e-mail de confirmação, emitir a nota fiscal, avisar a transportadora.
O jeito mais direto é fazer tudo na mesma requisição, chamando cada serviço e esperando a resposta. Esse modelo síncrono tem três problemas:
- A resposta demora a soma de tudo. Se a emissão da nota leva três segundos, o cliente espera três segundos a mais para ver "pedido confirmado".
- Uma falha derruba o resto. Se o serviço de e-mail está fora do ar, a compra falha, embora o e-mail pudesse ser enviado depois.
- Picos atingem todos ao mesmo tempo. Numa promoção, cada serviço recebe a carga inteira no mesmo instante.
No modelo assíncrono, a requisição faz só o essencial (registrar o pedido) e publica uma mensagem dizendo "o pedido 981 foi criado". Os outros trabalhos acontecem depois, cada um no seu ritmo, a partir dessa mensagem.
As peças
| Peça | Papel |
|---|---|
| Produtor | Publica a mensagem. Não sabe quem vai processá-la, nem quando |
| Intermediário (broker) | Recebe, guarda e entrega as mensagens. Exemplos: RabbitMQ, Kafka, Amazon SQS |
| Consumidor | Recebe a mensagem e faz o trabalho |
| Mensagem | Os dados do pedido de trabalho ou do fato ocorrido, em geral um JSON pequeno |
┌──────────────┐
serviço de pedidos ──▶ │ intermediário│ ──▶ envio de e-mail
(produtor) │ (fila) │ ──▶ emissão de nota
└──────────────┘ ──▶ aviso à transportadora
(consumidores)O produtor e os consumidores não se conhecem. Um serviço novo que precise saber dos pedidos criados só passa a consumir as mensagens, sem nenhuma mudança no serviço de pedidos.
O que se ganha
| Ganho | Exemplo |
|---|---|
| Resposta rápida | O cliente vê a confirmação depois de registrar o pedido, sem esperar e-mail e nota |
| Falhas isoladas | Se o serviço de e-mail cai, as mensagens esperam na fila e são processadas quando ele volta |
| Picos absorvidos | Mil pedidos num minuto viram mil mensagens na fila; os consumidores processam no ritmo que aguentam |
| Escala independente | Se a emissão de notas atrasa, sobe-se mais consumidores só para ela |
| Novas tentativas | Uma mensagem que falhou pode ser processada de novo, sem o usuário refazer nada |
Fila de tarefas e log de eventos
Os intermediários seguem dois modelos diferentes, e confundir os dois é a origem de muitas escolhas erradas.
Fila de tarefas
Cada mensagem é um trabalho a fazer. Ela é entregue a um consumidor e, quando ele confirma que terminou, é removida da fila. Vários consumidores na mesma fila dividem o trabalho entre si, como caixas de um supermercado atendendo uma fila única.
É o modelo do RabbitMQ, do Amazon SQS e da maioria das bibliotecas de tarefas em segundo plano.
Log de eventos
Cada mensagem é um fato que aconteceu, gravado no fim de um registro que só cresce. A mensagem não é removida quando alguém a lê: ela fica guardada pelo tempo configurado, dias ou para sempre. Cada consumidor guarda até onde já leu (a sua posição, ou offset).
Isso permite coisas que uma fila não permite:
- vários sistemas leem os mesmos eventos, cada um no seu ritmo;
- um consumidor novo pode ler todo o histórico desde o início;
- um consumidor com defeito pode ser corrigido e voltar a ler a partir de ontem.
É o modelo do Kafka, do Amazon Kinesis e do Redis Streams.
| Fila de tarefas | Log de eventos | |
|---|---|---|
| A mensagem representa | Um trabalho a fazer | Um fato que aconteceu |
| Depois de processada | É removida | Continua guardada |
| Vários consumidores | Dividem as mensagens | Cada grupo recebe todas |
| Reler o passado | Não | Sim |
| Exemplo típico | Enviar este e-mail | O pedido 981 foi criado |
A confirmação e a entrega repetida
Um consumidor recebe a mensagem, faz o trabalho e confirma (ack) ao intermediário. Só então a mensagem é considerada processada. Se o consumidor cair antes de confirmar, o intermediário entrega a mensagem de novo, para ele ou para outro consumidor.
Esse mecanismo garante que nenhuma mensagem se perca. Mas tem uma consequência inevitável:
consumidor recebe "enviar e-mail do pedido 981"
consumidor envia o e-mail ✔
consumidor cai antes de confirmar ✘
intermediário entrega a mensagem de novo
outro consumidor envia o e-mail ✔ ← o cliente recebe dois e-mailsO consumidor não tem como saber se a confirmação chegou. Por isso, quase todos os sistemas de mensageria oferecem entrega pelo menos uma vez (at-least-once): toda mensagem chega, e às vezes chega mais de uma vez.
Ordem
Uma fila com um único consumidor entrega as mensagens em ordem. Com vários consumidores em paralelo, a ordem se perde: a mensagem 2 pode terminar antes da 1. Com novas tentativas, uma mensagem que falhou volta depois das seguintes.
Se a ordem importa, ela precisa ser garantida por chave: todas as mensagens do mesmo pedido vão para a mesma partição e são processadas em sequência, enquanto pedidos diferentes são processados em paralelo. O Kafka faz isso com a chave da mensagem; filas com grupos de mensagens, como as filas FIFO do SQS, oferecem o mesmo.
Por que isso importa quando a IA escreve o código
Um assistente monta um produtor e um consumidor funcionando em minutos. O que fica de fora é o comportamento quando algo dá errado:
- O consumidor confirma a mensagem assim que a recebe, antes de processar, e uma queda no meio perde o trabalho.
- O consumidor não é idempotente, e uma reentrega cobra o cliente duas vezes.
- Uma mensagem com defeito falha, volta para a fila, falha de novo, e trava o consumo de todas as outras.
- O pedido é gravado no banco e a mensagem é publicada depois, e uma falha entre os dois deixa um pedido que nenhum outro serviço conhece.
O próximo nível compara os intermediários e mostra como tratar falhas, novas tentativas e ordem.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Mensageria em cinco minutos
Explique em no máximo cinco minutos de leitura o que são filas e mensageria no backend, para alguém que programa mas sempre fez tudo com chamadas síncronas. Cubra só o essencial: a diferença entre esperar e não esperar a resposta, o papel do produtor, do intermediário e do consumidor, a diferença entre fila de tarefas e log de eventos, e por que uma mensagem pode chegar duas vezes. Use o exemplo de uma loja que envia e-mail e emite nota fiscal depois da compra. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
Do síncrono ao assíncrono
Quero entender quando e por que trocar chamadas síncronas por mensageria. Aja como um mentor de backend. Pergunte primeiro qual é a minha experiência e como o sistema em que eu trabalho se comunica hoje. Use o exemplo de finalizar uma compra, que precisa registrar o pedido, cobrar, baixar o estoque, enviar e-mail, emitir nota e avisar a transportadora. Conduza assim, uma etapa por vez: 1. Monte a versão totalmente síncrona e pergunte quais problemas eu vejo nela. 2. Explique os três problemas principais: tempo de resposta, propagação de falhas e picos de carga. 3. Pergunte quais etapas eu tiraria do caminho do usuário e por quê. 4. Mostre a versão com mensageria e o que muda para o usuário, para cada serviço e para quem opera o sistema. 5. Explique o que o sistema perde ao ficar assíncrono: consistência imediata e simplicidade de depuração. Espere a minha resposta em cada etapa antes de continuar.
Fila de tarefas ou log de eventos
Quero entender de vez a diferença entre uma fila de tarefas, como o RabbitMQ, e um log de eventos, como o Kafka. Explique os dois modelos com uma analogia e depois tecnicamente: o que acontece com a mensagem depois de lida, como vários consumidores se comportam, o que é a posição de leitura (offset) e o que significa reler o passado. Depois me apresente seis necessidades, uma por vez, e pergunte qual modelo eu usaria: 1. Enviar o e-mail de boas-vindas depois do cadastro. 2. Três serviços diferentes que precisam reagir a cada pedido criado. 3. Gerar miniaturas das fotos enviadas pelos usuários. 4. Um serviço novo que precisa conhecer todos os pedidos dos últimos três meses. 5. Registrar cliques do site para análise. 6. Processar pagamentos com novas tentativas e atrasos. Corrija cada resposta explicando o motivo.
Por que a mensagem chega duas vezes
Quero entender por que a maioria dos sistemas de mensageria entrega cada mensagem pelo menos uma vez, e não exatamente uma vez. Explique: 1. O mecanismo de confirmação (ack) e o que acontece quando o consumidor cai antes de confirmar. 2. Uma linha do tempo em que a mesma mensagem é processada duas vezes. 3. A diferença entre entrega no máximo uma vez, pelo menos uma vez e exatamente uma vez, com o que cada uma custa. 4. Por que "exatamente uma vez" só existe dentro de limites específicos. 5. O que é um consumidor idempotente e três formas de construí-lo. Depois me mostre quatro consumidores e pergunte se cada um é idempotente e o que acontece numa reentrega. Corrija as minhas respostas.