Schedulers e tarefas periódicas sem depender de cron ingênuo

O problema

Tarefa periódica parece a coisa mais simples do mundo:

• roda a cada hora
• recalcula alguma coisa
• manda um email
• limpa um estado

Só que, com o tempo, aparecem problemas previsíveis:

• uma execução invade a próxima
• volume cresce e a janela não cabe mais
• deploy dispara duplicação
• a tarefa falha no meio e ninguém percebe

O cron continua lá.

O desenho é que não acompanhou a realidade.

Modelo mental

Vale pensar em tarefa periódica como um fluxo com quatro perguntas:

• quando ela precisa rodar?
• qual escopo ela processa por execução?
• o que acontece se atrasar?
• o que acontece se repetir?

Sem isso, o sistema fica dependente de “rezar para o cron passar”.

Exemplo simples

Imagine uma tarefa que fecha faturas vencidas diariamente.

Se o volume crescer, ela pode:

• não terminar a tempo
• pegar item demais numa execução
• repetir item na próxima janela

O problema não é a periodicidade.

É tratar o trabalho como bloco monolítico e invisível.

Uma leitura melhor costuma envolver:

• janela clara
• chunking ou paginação
• checkpoint
• idempotência por item

O erro comum

O erro comum é assumir três coisas ao mesmo tempo:

• só existe uma instância rodando
• sempre termina antes da próxima
• repetir não causa dano

Quando qualquer uma dessas três cai, o cron ingênuo começa a produzir efeito esquisito.

Onde a maturidade aparece

Scheduler mais maduro costuma responder:

• existe lease ou coordenação para evitar sobreposição?
• a execução é retomável?
• o job processa por lote seguro?
• atraso gera fila acumulada, skip ou catch-up?

Não precisa virar plataforma de workflow.

Mas precisa ser pensada como operação de verdade.

Quando cron ainda basta

Cron ainda é ótimo quando:

• o trabalho é simples
• o escopo é pequeno
• a repetição é tolerável
• o dano de atraso é baixo

O ponto não é demonizar cron.

É parar de tratá-lo como solução mágica para qualquer recorrência.

Como um senior pensa

Quem já sofreu com tarefa periódica ruim costuma perguntar:

• por que isso é periódico e não orientado a evento?
• se a execução atrasar, qual backlog nasce?
• se duas instâncias rodarem juntas, o que quebra?
• como limito o escopo de cada rodada?

Essas perguntas deixam a tarefa menos ingênua sem torná-la pomposa.

Ângulo de entrevista

Esse tema aparece em backend, ops, billing, limpeza de dados e pipelines internos.

O entrevistador quer ver se você entende:

• que cron também precisa de desenho de execução
• que periodicidade não elimina necessidade de idempotência e observabilidade
• que escopo e sobreposição importam tanto quanto agendamento

Resposta forte costuma soar assim:

“Eu trataria a tarefa periódica como fluxo operacional. Definiria janela, escopo por execução, comportamento em atraso e proteção contra sobreposição. Cron pode ser o gatilho, mas não substitui o desenho do processamento.”

Takeaway direto

Cron bom não é o que roda no horário.

É o que continua seguro quando o mundo real sai do horário.