Nota técnica
Kafka vs batch
Quando o job horário basta — e quando o pico de 20 minutos exige evento em fluxo.
- Kafka
- Spark
- Python
01 — Problema
Batch de hora em hora não observa fila nem SLA no momento em que a operação ainda pode agir.
02 — Hipótese
Streaming justifica-se por latência de decisão, não por ter Kafka no diagrama.
03 — Implementação
Delivery Audit permanece batch; Streaming Operations descreve Kafka + janela só para alerta.
04 — Resultado
Dois contratos: Gold diário para tendência; estado por pedido em fluxo para alerta.
05 — Aprendizado
Colocar broker cedo, sem consumidor nem regra, só aumenta superfície operacional.
O Delivery Audit é batch. O Streaming Operations é a evolução para evento. A decisão não é “qual ferramenta é moderna”.
Problema
| Necessidade | Batch (hora / dia) | Stream |
|---|---|---|
| Tendência de cancelamento | Adequado | Desperdício |
| Auditoria de regra de negócio | Adequado | Possível em janela |
| Fila estourando agora | Tarde demais | Adequado |
| Replay de ontem | Natural (partição) | Exige tópico retido |
Operação de delivery sente pico de 20 minutos. Relatório de ontem não fecha a loja às 19h.
Hipótese
Usar Kafka quando a decisão precisa acontecer no mesmo intervalo do evento. Manter Parquet + job quando o valor está na reconstrução e no grão estável.
Exactly-once no slide não é o MVP. At-least-once + dedup por order_id cobre alerta de fila.
Implementação
- Batch: API mock → Bronze/Silver/Gold → auditoria → Streamlit.
- Stream (desenho): mesmo mock publica em tópico
orders/status→ consumidor persiste último estado → regra “N pedidos em preparo há M minutos” → Slack.
O Gold batch não some. Stream alimenta alerta; o fato continua sendo a fonte de tendência.
Resultado
Dois modos de falha, dois desenhos. Sem misturar “dashboard em tempo real” com “KPI do mês” no mesmo sink.
Aprendizado
A pergunta útil: o que a operação faz de diferente se o dado chegar em 30 segundos em vez de 60 minutos? Se a resposta for “nada”, o batch ainda é o sistema certo.