Batch vs tempo real: a diferença entre expectativa e realidade
"Precisa atualizar na hora." A frase vem com urgência e expectativa de experiência perfeita. A pergunta que quase ninguém faz antes de prometer é: esse sistema foi feito pra rodar em tempo real? A diferença entre batch e tempo real é estrutural.
Batch é quando o sistema processa em intervalos: a cada 5 minutos, meia hora, uma vez por dia. Junta informação e processa em lote. Funciona — mas não é na hora. Tempo real é: o evento acontece, o sistema processa na hora. Só que tempo real exige infra mais robusta, monitoramento, capacidade de aguentar pico e custo operacional maior. Não é "mais rápido"; é outro tipo de desenho. O usuário vê a tela e não sabe se atrás tem fila, sincronização ou réplica. O negócio traduz: "Precisa ser na hora." Só que "na hora" pode ser 100 ms, 1 segundo, 5 segundos ou 5 minutos. Sem clareza você promete o absoluto.
Sistema financeiro: o cliente paga e o negócio pede "O saldo tem que atualizar na hora em todo lugar." O saldo é calculado em tempo real ou consolidado em batch? O dashboard puxa de onde? Se o sistema foi feito pra consolidar saldo a cada 15 minutos, pedir atualização instantânea pode significar reescrever processamento, mudar modelo, subir custo de infra. Muitas vezes o negócio não precisa de tempo real de verdade; precisa da sensação de que é ágil. Dá pra confirmar a ação pro usuário na hora e deixar o processamento interno terminar alguns segundos depois. Tempo real não é só performance. É escalar o tempo todo, alta disponibilidade, monitoramento 24/7. Sistema batch pode cair 10 minutos e o impacto ser aceitável; em tempo real a crise pode ser imediata.
Essa informação precisa ser instantânea? Ou processada em poucos minutos? Qual o impacto real de atrasar? Muitas vezes a resposta é: não precisa ser imediato, só previsível. Previsibilidade costuma ser mais barata que instantaneidade. "O estoque tem que atualizar em tempo real." Se o sistema foi feito pra atualizar em batch a cada 5 minutos, migrar pra tempo real pode significar reescrever integração, criar processamento orientado a eventos. Não é "mudar consulta"; é mudar arquitetura. Em sistema distribuído, um serviço fala com outro pela rede. Se você exige que vários serviços respondam na hora antes de mostrar algo, está somando latências. Tela chama A, B, C e D — cada um 200 ms. Já deu quase 1 segundo. Tempo real não é só intenção; tem limite físico.
Antes de qualquer requisito que fale em "atualizar na hora": o sistema hoje é batch ou tempo real? A infra aguenta? Qual o SLA atual? Se você não sabe responder, ainda não tem base pra prometer. Quem leva o papel a sério pergunta: "Qual é o problema de verdade que a gente está tentando resolver?" Às vezes o problema não é atraso de 5 minutos; é falta de visibilidade. O que resolve é clareza de expectativa, não reestruturação técnica. Muitas empresas começam em batch; conforme crescem aparece pressão por tempo real. Mudar arquitetura exige planejamento e investimento. Exigir tempo real em pontos soltos, sem estratégia, vira remendo.
Sempre que alguém disser "Precisa atualizar na hora", não responda no automático. Pergunte: o sistema foi desenhado pra isso? O custo compensa? Tempo real não é feature; é decisão arquitetural.
No próximo post: latência. Porque segundos importam — e somam.
