Batch e streaming: quando cada forma de processar faz sentido

O problema

Batch e streaming costumam ser discutidos como se um fosse velho e o outro fosse evoluído.

Essa conversa normalmente piora a decisão.

Porque o ponto não é parecer moderno.

O ponto é escolher uma forma de processamento compatível com:

• latência exigida
• volume
• custo
• simplicidade operacional

Tem sistema rodando streaming sem precisar.

E tem sistema preso em lote quando o valor do dado morre rápido demais.

Modelo mental

Batch costuma significar:

• processar conjunto acumulado
• em janela maior
• com atraso aceitável

Streaming costuma significar:

• reagir continuamente
• com atraso bem menor
• mais perto do momento em que o fato acontece

No meio existe muita coisa útil:

• fila com consumidor contínuo
• microbatch
• job recorrente de poucos minutos

Na prática, a decisão raramente é binária.

Quando batch faz sentido

Batch tende a ser ótimo quando:

• atraso é aceitável
• o objetivo é consolidar volume
• o custo por item cai ao processar em conjunto
• o negócio não precisa reagir imediatamente

Exemplos:

• reconciliação financeira
• exportação grande
• backfill
• recomputar indicadores do dia

Nesses casos, tentar empurrar tudo para streaming pode só adicionar custo, complexidade e fragilidade.

Quando streaming faz sentido

Streaming ou quase tempo real faz mais sentido quando:

• o valor da informação cai rápido
• a reação imediata muda experiência ou risco
• filas de atraso já prejudicam produto ou operação

Exemplos:

• alerta de fraude
• atualização operacional crítica
• evento que dispara experiência do usuário em poucos segundos

Aqui o batch pode existir, mas provavelmente já não atende o produto.

O meio do caminho costuma ser ignorado

Muita decisão ruim vem de ignorar o meio do caminho.

Às vezes você não precisa de pipeline sofisticado de streaming.

Talvez baste:

• um job a cada 1 minuto
• consumidor de fila com janela pequena
• microbatch a cada poucos segundos

Isso já reduz atraso sem comprar a complexidade total de um stack de streaming mais pesado.

Exemplo simples

Imagine três fluxos diferentes.

1. Relatório financeiro diário

Batch é natural.

Ninguém precisa desse fechamento em 200 milissegundos.

2. Atualização de painel operacional quase em tempo real

Talvez microbatch ou fila contínua já resolvam.

O requisito não é milissegundo.

É poucos segundos com previsibilidade.

3. Detecção de fraude na autorização

Aqui o atraso costuma ter custo direto.

Streaming ou processamento contínuo faz muito mais sentido.

Os três casos têm “dados”.

Mas pedem formas de processamento diferentes.

O erro comum

O erro comum é usar linguagem de escala antes de usar linguagem de necessidade.

O time fala:

• Kafka
• stream processor
• event pipeline

antes de responder:

• qual atraso o negócio tolera?
• o que muda se isso chegar em 2 segundos, 2 minutos ou 2 horas?
• quanto custa operar essa escolha?

Sem isso, a arquitetura parece forte no diagrama e fraca no critério.

Como um senior pensa

Quem tem mais julgamento normalmente pergunta:

• o valor desse processamento vence quando?
• qual é a janela aceitável?
• dá para resolver com batch menor?
• o custo operacional do streaming se paga aqui?
• como reprocessar isso se der problema?

Essa é a diferença entre escolha técnica e preferir ferramenta.

Ângulo de entrevista

Esse tema aparece em system design, data-heavy backend e cenários de eventos.

O entrevistador quer ver se você:

• diferencia latência necessária de latência desejável
• sabe defender lote quando ele é suficiente
• não vende tempo real só porque parece sofisticado
• entende retry, reprocessamento e custo operacional

Resposta forte costuma soar assim:

“Eu escolheria a forma de processamento a partir da janela de reação que o negócio realmente exige. Se alguns minutos bastam, batch ou microbatch podem ser muito mais simples. Streaming eu reservaria para casos em que atraso pequeno realmente muda risco, operação ou experiência.”

Takeaway direto

Forma de processamento boa não é a mais moderna.

É a que entrega a latência necessária pelo menor custo de complexidade que ainda faz sentido.