Filas e mensageria em sistemas: quando usar e quando evitar

Sexta-feira, fim de tarde, campanha no ar. A loja virtual recebe pedidos num ritmo que nunca viu, e o sistema que manda cada pedido para o ERP começa a demorar. Em algum momento o ERP para de responder por alguns minutos. Quando volta, ninguém sabe ao certo quais pedidos chegaram, quais ficaram pelo caminho e quais entraram duas vezes.

Na segunda-feira, alguém passa a manhã cruzando o painel da loja com o ERP, pedido por pedido, e o financeiro descobre notas que não foram emitidas. Ninguém errou sozinho: o desenho do sistema assumia que o outro lado sempre estaria disponível na hora exata em que fosse chamado.

Filas e mensageria existem para quebrar essa suposição. Em vez de um sistema exigir que o outro responda no mesmo instante, ele deixa a tarefa guardada num lugar seguro, e o destino a processa assim que puder. Se o destino cair, a tarefa espera; se falhar, fica registrada para nova tentativa. Este texto explica, sem jargão desnecessário, o que isso resolve, onde se paga e onde só adiciona peças que alguém vai precisar manter.

A resposta curta: quando uma fila vale a pena

Uma fila vale a pena quando pelo menos uma destas situações é real no seu negócio, e não hipotética:

• O outro sistema cai ou fica lento e você não controla isso. ERP de terceiro, SEFAZ, transportadora, gateway de pagamento, marketplace.
• A carga chega em picos. Campanha, fechamento de mês, virada de lote, abertura de inscrições.
• Uma tarefa demora e o usuário não precisa esperar por ela. Gerar relatório pesado, emitir nota, processar arquivo de retorno do banco, enviar centenas de e-mails.
• Um acontecimento precisa disparar várias reações independentes. Um pedido aprovado precisa reservar estoque, avisar a expedição, atualizar o CRM e notificar o cliente.
• Perder uma operação custa caro. Um pedido, um pagamento ou uma nota que some sem deixar rastro.

Se nenhuma dessas é verdade hoje, provavelmente uma fila é complexidade que você ainda não precisa. Mais adiante há critérios para decidir com calma.

O pedido que se perde quando o outro sistema cai

O desenho mais comum de integração é a chamada direta: a loja recebe o pedido e, na mesma hora, chama o ERP para gravá-lo. Funciona bem enquanto os dois lados estão de pé e rápidos. O problema aparece nas bordas:

• O ERP está fora do ar. A chamada falha. Se o código não guarda o pedido em algum lugar para tentar de novo, ele simplesmente não chega.
• O ERP está lento. A loja fica esperando, o cliente fica esperando, e em pico as conexões se acumulam até que a própria loja começa a falhar.
• A resposta se perde no caminho. O ERP gravou o pedido, mas a confirmação não voltou. A loja tenta de novo e o pedido entra duplicado.

O desenho completo de integração com ERP, incluindo esses cenários, está em como integrar seu sistema com o ERP.

O que é uma fila em linguagem simples

Pense na bandeja de entrada de um setor. Quem precisa de algo deixa o pedido na bandeja e segue com o trabalho. Quem atende pega da bandeja no ritmo que consegue. Se o atendente sai para almoçar, os pedidos não se perdem: esperam na bandeja.

Uma fila de mensagens é essa bandeja, em software:

• Produtor é quem deixa a mensagem (a loja que recebeu o pedido).
• Fila é onde a mensagem fica guardada, de forma durável, até ser processada.
• Consumidor é quem retira e processa (o serviço que grava o pedido no ERP).
• Confirmação é o aviso do consumidor de que terminou. Só então a mensagem sai da fila. Se ele cair no meio, a mensagem volta a ficar disponível.

O ganho central é o desacoplamento no tempo: o produtor não depende de o consumidor estar disponível naquele segundo. A loja continua aceitando pedidos mesmo com o ERP fora; quando ele volta, o consumidor esvazia a fila.

Há várias ferramentas para isso, de serviços gerenciados dos provedores de nuvem a ferramentas como RabbitMQ e, para volumes muito altos de eventos, Kafka. A ferramenta importa menos do que as regras de negócio em volta dela.

Processamento em segundo plano

O uso mais simples de fila nem envolve outro sistema. É tirar do caminho do usuário aquilo que ele não precisa esperar.

Exemplos do dia a dia:

• Relatório gerencial pesado. Em vez de travar a tela por minutos, o sistema registra o pedido, devolve "seu relatório está sendo gerado" e avisa quando o arquivo estiver pronto.
• Importação de planilha grande. O arquivo entra na fila, cada linha é processada e validada, e o usuário vê o progresso e os erros ao final.
• Emissão de nota fiscal. O pedido é aprovado na hora; a emissão segue em segundo plano, com novas tentativas se a SEFAZ estiver instável, e o status fica visível para o faturamento.

O efeito em picos de demanda

Em pico, a fila funciona como um amortecedor. Entram mil pedidos em poucos minutos, mas o ERP só aguenta gravar num ritmo menor. Sem fila, ou o ERP cai, ou a loja recusa vendas. Com fila, a loja aceita tudo e o ERP processa no ritmo dele. A fila cresce durante o pico e esvazia depois.

O preço é que o dado deixa de ser instantâneo: o pedido pode levar alguns minutos para aparecer no ERP. Para a maioria das operações isso é aceitável. Para outras, como reserva de estoque em promoção agressiva, é preciso desenhar com cuidado o que precisa ser imediato e o que pode esperar.

Eventos: um acontecimento, várias reações

O passo seguinte é a arquitetura orientada a eventos. Em vez de um sistema chamar diretamente cada interessado, ele publica um fato: "pedido 4821 foi aprovado". Quem tiver interesse nesse fato reage por conta própria. Entre sistemas de empresas diferentes, esse aviso costuma chegar por webhook.

A vantagem aparece quando o negócio muda. Precisa incluir um programa de fidelidade que pontua a cada compra? Cria-se um novo consumidor do evento "pedido aprovado". O sistema de pedidos não é alterado, não precisa ser testado de novo e não corre risco de quebrar.

O cuidado que os eventos exigem

Eventos trocam acoplamento direto por acoplamento ao formato da mensagem. Se o evento "pedido aprovado" muda de estrutura sem aviso, todos os consumidores quebram juntos. Por isso, em arquitetura orientada a eventos:

• O formato de cada evento é documentado e versionado, como um contrato.
• Mudanças que quebram compatibilidade convivem com a versão anterior por um período.
• Cada evento tem um identificador único, para que o consumidor saiba se já o processou.

Também fica mais difícil responder "o que aconteceu com o pedido 4821?", porque a história fica espalhada. Por isso monitoramento é parte do projeto, não etapa final.

Reprocessamento e mensagens com erro

Fila não elimina erro. Ela muda o erro de lugar: em vez de sumir, ele fica guardado esperando decisão. Isso só é vantagem se o sistema souber o que fazer com ele.

Tentar de novo, com critério

Falhas temporárias, como ERP fora do ar ou SEFAZ lenta, se resolvem tentando de novo. O padrão é repetir com intervalos crescentes: alguns segundos, depois um minuto, depois alguns minutos. Repetir sem intervalo só aumenta a pressão sobre quem já está com problema.

Falhas permanentes não se resolvem com novas tentativas. Um pedido com CNPJ inválido, um produto que não existe no ERP, um campo obrigatório vazio. Tentar mil vezes dá mil erros iguais.

A fila de mensagens com erro

Depois de um número definido de tentativas, a mensagem vai para uma fila separada, de mensagens com erro (no jargão, dead letter queue). Ela não trava as outras e não se perde. Alguém da operação consegue:

1. Ver quais mensagens falharam e o motivo.
2. Corrigir o dado na origem ou no destino.
3. Reenviar a mensagem para processamento com um clique.

Sem ela, o erro vira log que ninguém lê.

Idempotência: processar duas vezes sem estragar nada

Em mensageria, a garantia mais comum é que cada mensagem será entregue pelo menos uma vez. Na prática, às vezes ela chega duas. Por isso o consumidor precisa ser idempotente: processar a mesma mensagem duas vezes tem que produzir o mesmo resultado que processar uma.

Para pedidos, isso significa verificar se aquele identificador já foi gravado antes de gravar de novo. Para notas fiscais, verificar se já existe nota emitida para aquele pedido antes de emitir outra. É um detalhe técnico que separa uma integração confiável de uma que duplica cobrança.

Quando a mensageria é complexidade demais

Fila e eventos adicionam peças: um serviço a mais para operar, mensagens para monitorar, cenários de erro novos para testar. Em vários casos, isso não se paga:

• Volume baixo e estável. Algumas dezenas de operações por dia, sem picos, com sistemas que raramente caem.
• O usuário precisa da resposta na hora. Consultar saldo, validar login, calcular frete na tela de compra. Isso é requisição e resposta, não fila.
• Um único sistema, um único time. Muitas vezes uma rotina agendada ou uma tabela de tarefas pendentes no próprio banco resolve com muito menos peças.
• Ninguém vai olhar a fila de erros. Se não há quem cuide das mensagens com falha, a fila só esconde o problema por mais tempo.

O mesmo raciocínio vale para a discussão sobre separar o sistema em serviços: complexidade distribuída tem custo fixo alto, e só se justifica quando o problema é real. A análise completa está em monolito ou microsserviços. Um monolito bem feito pode usar filas internamente sem virar uma constelação de serviços.

Critérios para decidir

Use esta lista na próxima conversa com a equipe técnica ou com o fornecedor:

• Quantas vezes, nos últimos meses, uma integração falhou e alguém precisou corrigir à mão?
• Existe pico previsível de volume? O sistema aguentou o último?
• Há tarefas que travam a tela do usuário e poderiam rodar depois?
• Um mesmo acontecimento precisa avisar três ou mais sistemas?
• Perder ou duplicar uma operação gera prejuízo, retrabalho fiscal ou cliente insatisfeito?
• Existe alguém na operação para tratar mensagens com erro?

Se a maioria das respostas aponta para falhas frequentes, picos e várias reações por acontecimento, a mensageria tende a se pagar. Se as respostas são "quase nunca" e "não", comece pelo simples e reavalie quando o cenário mudar.

Monitorando filas na operação

Uma fila que ninguém observa é um lugar onde problemas ficam escondidos. Os indicadores mínimos que recomendamos acompanhar:

O indicador mais útil para quem decide costuma ser a idade da mensagem mais antiga. "A fila tem 300 mensagens" diz pouco. "O pedido mais antigo está esperando há 40 minutos" diz exatamente se há um problema para o cliente.

Cada um desses indicadores deve ter um alerta que chega a uma pessoa, não só um gráfico num painel. E cada mensagem deve carregar um identificador que permita seguir o caminho do pedido por todos os sistemas. Como montar essa visibilidade está em observabilidade: logs, métricas e traces.

Passo a passo para colocar uma fila em produção

1. Mapeie os fluxos críticos. Quais operações não podem se perder e quais sistemas externos participam delas.
2. Defina o que é imediato e o que pode esperar. Escreva o tempo aceitável de atraso de cada fluxo em linguagem de negócio.
3. Desenhe o formato das mensagens. Com identificador único e versão, documentado.
4. Implemente consumidores idempotentes. E teste o cenário de mensagem duplicada antes de ir para produção.
5. Configure novas tentativas e a fila de erros. Com limites definidos e uma tela para reprocessar.
6. Ligue alertas antes de ligar o fluxo. Tamanho, idade e erros, com responsável nomeado.
7. Teste o pior caso. Desligue o sistema de destino em homologação e confira se nada se perde quando ele volta.

Perguntas frequentes

Qual a diferença entre fila e webhook?

Webhook é um aviso que um sistema envia a outro quando algo acontece, normalmente entre empresas diferentes. Fila é o lugar onde a tarefa fica guardada até ser processada. Os dois costumam trabalhar juntos: o sistema recebe o webhook, grava a mensagem numa fila e responde rápido, deixando o processamento pesado para logo depois.

Qual a diferença entre RabbitMQ e Kafka?

RabbitMQ é um intermediador de mensagens tradicional, em que a mensagem sai da fila depois de processada, e atende bem à maior parte das integrações de empresas médias. Kafka guarda os eventos como um registro contínuo, que pode ser relido, e foi pensado para volumes muito altos. Na maioria dos casos, a ferramenta importa menos que as regras de negócio.

Uma fila de mensagens pode perder dados?

Uma fila de mensagens bem configurada guarda a mensagem de forma durável e só a remove depois da confirmação do consumidor, então a perda é rara. O risco mais comum é o oposto: a mesma mensagem chegar duas vezes. Por isso o consumidor precisa ser idempotente, e as falhas definitivas devem ir para uma fila de erros com responsável.

Usar fila deixa o sistema mais lento?

Para o usuário, não: ele deixa de esperar por tarefas demoradas. O que muda com a fila é que o dado deixa de ser instantâneo no sistema de destino, e um pedido pode levar alguns minutos para aparecer no ERP em momentos de pico. Para a maioria das operações esse atraso é aceitável, desde que o tempo tolerado esteja definido.

Como a Pervian Tech trabalha arquitetura de integrações

Na Pervian Tech, começamos pelo mapa dos fluxos e das falhas, não pela ferramenta. Levantamos quais operações não podem se perder, quais sistemas externos são instáveis e onde estão os picos. A partir disso, decidimos onde uma fila resolve, onde uma chamada direta basta e onde uma rotina agendada é suficiente. Esse trabalho faz parte do nosso serviço de arquitetura de software e, quando o foco é ligar sistemas, da nossa solução de integração de sistemas.

Todo projeto é sob medida, porque a mesma fila que salva um e-commerce em campanha seria exagero para uma operação com volume baixo e estável. O ponto de partida é um diagnóstico inicial gratuito, e o investimento é definido sob consulta, depois que o escopo real está claro. Outros textos sobre decisões técnicas estão na categoria engenharia.

Se pedidos, notas ou integrações estão se perdendo no caminho, conte o que está acontecendo.