Uma importação atrasou e a solução imediata foi aumentar a quantidade de workers. Por alguns minutos a fila diminuiu; depois, o banco ficou lento e o fornecedor começou a recusar requisições. O gargalo não desapareceu: foi pressionado por mais concorrência.
Uma fila saudável precisa equilibrar entrada, capacidade de processamento e limites dos serviços dependentes. Backpressure é o controle que reduz ou regula a pressão quando uma parte do fluxo não consegue acompanhar a outra.
O número de mensagens não conta toda a história
Uma fila com milhares de tarefas curtas pode estar dentro do esperado. Uma fila com poucas tarefas antigas pode esconder um bloqueio grave. Acompanhe idade, taxa de entrada, taxa de conclusão, duração por tarefa e distribuição dos erros.
A documentação do RabbitMQ explica conceitos de filas, entrega e confirmação. Esses mecanismos ajudam a transportar trabalho, mas a conclusão de uma tarefa de negócio precisa ser definida pela aplicação. Receber uma mensagem não significa ter atualizado corretamente o sistema de destino.
Diagnostique antes de aumentar recursos
Em um cenário hipotético, um ERP envia pedidos para um operador logístico. A entrada aumentou durante uma campanha, mas o limite de chamadas do parceiro permaneceu igual. Dobrar os consumidores pode apenas produzir mais recusas e retentativas.
O diagnóstico precisa separar espera legítima, falha temporária, mensagem inválida e limitação externa. Cada categoria pede uma política. Repetir um cadastro sem campo obrigatório não resolve o problema; esperar alguns segundos pode resolver uma indisponibilidade transitória, dentro de limites definidos.
| Sinal | Possível causa | Verificação útil |
|---|---|---|
| Tarefas antigas sem avanço | Bloqueio ou consumidor parado | Última confirmação e estado do worker |
| Erros aumentam com concorrência | Limite externo ou saturação | Respostas do parceiro e uso do banco |
| Uma mensagem reaparece sempre | Erro permanente ou efeito ambíguo | Conteúdo e histórico de tentativas |
| Fila cai, reclamações continuam | Confirmação antes da conclusão | Estado final no sistema de negócio |
Defina quando confirmar a mensagem
Confirmar cedo demais pode retirar o trabalho da fila antes de o efeito ser concluído. Confirmar tarde exige lidar com reentrega quando o consumidor falha após executar a operação. Essa tensão torna idempotência e rastreabilidade importantes.
Use uma identidade de negócio estável para reconhecer repetição. Se a tarefa já foi concluída, a nova entrega deve ser tratada conforme a regra do processo, sem duplicar cobrança, pedido ou mensagem ao cliente. O transporte não consegue decidir sozinho se dois eventos representam o mesmo efeito.
Retentativa precisa de fim e visibilidade
Defina quantidade de tentativas, intervalo e critério de interrupção. Esperas progressivas podem reduzir pressão durante falhas transitórias. Mensagens que não podem avançar devem ir para uma área de exceção visível, com responsável e procedimento de correção.
Uma fila de erros não deve ser um arquivo morto nem um botão para “reenviar tudo”. Antes de reprocessar, verifique se o efeito já ocorreu no destino, se o dado foi corrigido e se a ação ainda faz sentido. Em atendimento, mensagens antigas podem ser inadequadas depois de um humano já ter respondido.
Quando houver cancelamento, registre um estado que impeça a execução posterior. Apagar apenas uma lista intermediária pode deixar cópias em outro serviço. O controle precisa abranger o ponto que efetivamente autoriza o envio ou a alteração final.
Proteja a aplicação de picos
Limite concorrência por parceiro, tipo de tarefa ou organização quando necessário. Uma importação pesada de um cliente não deveria impedir operações essenciais de todos os outros. Prioridades devem ser poucas e compreensíveis; complexidade excessiva pode dificultar prever a ordem de atendimento.
Também defina capacidade de entrada. Se o serviço está saturado, a aplicação deve informar espera ou recusar de maneira controlada, em vez de aceitar trabalho sem possibilidade real de entrega. A promessa ao usuário deve corresponder ao compromisso que o sistema consegue sustentar.
Exercício de capacidade
Simule um pico representativo com dados fictícios. Aumente a entrada gradualmente e observe onde a latência se deteriora. Depois reduza a origem e verifique quanto tempo o sistema leva para voltar ao normal. Um serviço que processa bem em regime estável pode levar horas para recuperar um acúmulo.
O resultado esperado inclui limites conhecidos, alertas por atraso e um procedimento de recuperação. Não se resume a obter uma taxa máxima em um teste isolado.
Perguntas frequentes
Mais workers sempre aceleram a fila?
Não. Eles podem saturar banco, rede ou fornecedor. A concorrência deve respeitar o gargalo medido e a segurança do efeito executado.
Uma dead-letter queue resolve os erros?
Ela organiza mensagens que precisam de tratamento, mas não corrige a causa nem decide se é seguro reprocessar. É necessário um fluxo operacional.
Posso reenviar tarefas antigas automaticamente?
Somente quando a regra de negócio continuar válida e o sistema puder evitar efeitos duplicados ou inconvenientes. Algumas tarefas devem expirar ou ser canceladas.
Referência e aplicação
Consulte os conceitos de filas do RabbitMQ. O roteiro de capacidade e os exemplos são orientações editoriais, não uma configuração universal do broker.
Para fluxos automatizados, veja o guia de n8n em produção e avalie as integrações da A2CR.
