Do Hangfire ao RabbitMQ: Acabando com o Polling de Banco de Dados
O Hangfire é ótimo para equipes pequenas. Você adiciona um pacote NuGet e o aponta para o seu banco de dados. Você ganha um executor de jobs e um dashboard gratuitamente. Para um único serviço, é difícil de superar.
Eu usei o Hangfire no SavePosty para lidar com e-mails, webhooks e busca de conteúdo. Cada job funcionava da mesma maneira. Todos faziam polling no meu banco de dados Postgres a cada poucos segundos para verificar se havia novos trabalhos.
Eventualmente, mudei tudo para o RabbitMQ. Aqui está o porquê eu fiz isso e o que eu perdi.
Por que eu mudei:
- A carga de polling escala com o tempo, não com o trabalho. Cada job do Hangfire atinge seu banco de dados em um timer. Mesmo que não haja trabalho, o banco de dados permanece ocupado. Esse custo cresce conforme a contagem de jobs e a frequência de polling.
- Modelos demais. Uma parte do meu app já usava RabbitMQ. O restante usava Hangfire. Isso significava duas formas diferentes de gerenciar o trabalho em segundo plano. Mudar para o RabbitMQ unificou tudo.
- Latência. Um broker envia o trabalho no momento em que ele chega. O Hangfire espera pelo próximo polling.
As compensações:
O Hangfire é fácil de configurar. Ele usa suas tabelas SQL existentes. Possui um excelente dashboard integrado.
O RabbitMQ exige o gerenciamento de um broker. Ele utiliza RAM e rede em vez de CPU do banco de dados. Você obtém uma melhor escalabilidade, mas com mais sobrecarga operacional.
Como migrei com segurança:
Mantive minha lógica de negócio exatamente a mesma. Construí consumers leves que atuam como uma porta de entrada. O consumer recebe a mensagem e a entrega para a classe de job existente.
Eu foquei em duas coisas:
- Paridade de retentativa (retry parity). Eu igualei as configurações de retry do Hangfire no consumer do RabbitMQ para não perder mensagens.
- Segurança de esquema (schema safety). Mantive as colunas antigas como anuláveis (nullable) para não quebrar o banco de dados durante o deploy.
O que eu perdi:
A maior desvantagem é a visibilidade. O Hangfire permite que você clique em um job que falhou e veja exatamente o que aconteceu. O RabbitMQ mostra quantas mensagens estão em uma Dead Letter Queue, mas não oferece essa mesma visualização fácil por job. Agora, eu dependo de logs estruturados em vez de um dashboard.
Meu conselho:
Continue no Hangfire se:
- Você executa um único serviço.
- Você tem uma equipe pequena.
- Você precisa de um dashboard fácil para depuração.
Mude para o RabbitMQ se:
- Você tem múltiplos serviços.
- A carga do seu banco de dados devido ao polling é alta.
- Você deseja usar padrões pub/sub.
A decisão depende do seu sistema, não de um único job.
Fonte: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi