Toda automação começa com a mesma pergunta: o que faz isso rodar? Existem três respostas possíveis, elas não competem entre si, e escolher a errada produz sintomas bem característicos.
Cron: roda porque deu a hora
O cron executa em horários definidos. Toda madrugada, a cada quinze minutos, toda segunda de manhã.
Quando usar: quando o trabalho tem relação com tempo, e não com eventos. Relatório diário, limpeza de registros antigos, verificação de saúde, conciliação noturna. Também serve quando a origem do dado não avisa sobre mudanças e a única saída é ir conferir periodicamente.
O sintoma de uso errado: intervalo cada vez menor. Quando alguém reduz um cron de quinze minutos para cinco, depois para um, o que está sendo pedido não é agendamento, é reação. Esse é o momento de trocar por webhook.
A armadilha: execuções que se sobrepõem. Se a tarefa demora mais que o intervalo, a próxima começa antes de a anterior terminar, e duas instâncias trabalham no mesmo dado. É preciso garantir que só uma rode por vez.
Webhook: roda porque algo aconteceu
O webhook é o inverso. Em vez de perguntar periodicamente, você recebe um aviso quando o evento ocorre.
Quando usar: quando a reação precisa ser imediata e o sistema de origem oferece essa notificação. Pagamento aprovado, formulário enviado, mensagem recebida, alteração em repositório.
A vantagem real não é só velocidade, é eficiência: nada roda quando nada acontece. Um cron de um minuto executa mais de quarenta mil vezes por mês, quase sempre sem nada para fazer.
As três armadilhas:
- Ele chega quando quiser. Incluindo dez de uma vez, num pico que o seu fluxo não esperava.
- Ele pode chegar duas vezes. Muitos serviços reenviam quando não recebem confirmação rápida. Se o seu fluxo não for preparado para isso, você processa o mesmo evento em duplicidade.
- Ele pode não chegar. Se o seu servidor estava fora do ar no momento do envio, o evento pode se perder para sempre.
Essa última é o motivo pelo qual webhook e cron frequentemente convivem: o webhook faz o trabalho rápido, e um cron esporádico confere se algo escapou.
Fila: não decide quando, decide o ritmo
A fila é diferente das outras duas, e por isso a comparação costuma confundir. Ela não é um gatilho, é um amortecedor entre receber e executar.
O fluxo recebe o pedido, coloca numa fila e responde imediatamente que recebeu. Um processo separado consome a fila no ritmo que aguenta.
Quando usar: sempre que o volume de entrada for imprevisível ou o trabalho for demorado. Se uma execução leva trinta segundos e podem chegar vinte pedidos simultâneos, sem fila você tem vinte execuções competindo por memória.
O que a fila resolve de bônus: ela permite tentar de novo. Um item que falhou volta para a fila e é reprocessado, em vez de desaparecer. Isso transforma falha temporária de um serviço externo em atraso, não em perda.
O sintoma de falta de fila: o fluxo funciona bem quase sempre e quebra exatamente nos momentos de maior movimento, que são os momentos em que ele mais importa.
A combinação que resolve a maioria dos casos
Na prática, projetos maduros usam os três, cada um no seu papel:
- Webhook recebe o evento e não faz mais nada além de validar e enfileirar. Responde em milissegundos.
- Fila segura o volume e entrega ao processador no ritmo suportado, com nova tentativa quando algo falha.
- Cron roda de tempos em tempos para conferir o que não chegou e reprocessar o que ficou preso.
Essa arquitetura tem três propriedades difíceis de obter de outro jeito: aguenta pico sem cair, não perde evento e se recupera sozinha de falha temporária.
Como escolher em trinta segundos
Três perguntas resolvem:
- O que dispara isso: o relógio ou um acontecimento? Relógio, cron. Acontecimento, webhook.
- O trabalho demora mais do que alguém está disposto a esperar? Se sim, fila.
- Perder uma execução seria um problema sério? Se sim, fila, e cron de conferência.
A resposta certa costuma ser mais de uma, e está tudo bem. O erro não é usar três mecanismos, é tentar fazer um deles cobrir o papel dos outros dois.
Para rodar esse tipo de arquitetura com processo sempre ativo e fila, veja as opções de VPS da StayCloud.
