Micro-batch streaming contorna Kafka para atualização de índices de busca

Um post-mortem de produção publicado em maio de 2026 no InfoQ documenta como um pipeline de recuperação para busca e anúncios migrou de jobs batch agendados para Spark Structured Streaming em modo micro-batch. O relato do autor Parveen Saini revela onde a arquitetura falhou sob carga de produção: a equipe descobriu que delay de agendamento e overhead de orquestração, não computação, representavam o principal gargalo. O toolkit padrão para resolver esse problema carregava seus próprios modos de falha.

O pipeline mantinha um índice invertido suportado por Solr cobrindo vários milhões de documentos. Reconstruções completas levavam duas a três horas, com validação e deployment elevando o turnaround total para aproximadamente cinco horas, tornando reconstruções completas frequentes impraticáveis. O pipeline delta ingeria novos anúncios, atualizações de campanhas e sinais comportamentais como dados de co-purchase. Rodava em arquivos particionados por tempo em armazenamento de objeto estilo S3, recebendo novos dados incrementais a cada cinco a sete minutos. Cada execução delta cobria as últimas cinco horas de partições, com múltiplas execuções por hora esperadas. Uma lacuna de staleness de um ciclo de agendamento se traduzia diretamente em ativação de anúncio atrasada e resultados de recuperação obsoletos.

A equipe converteu os jobs batch para micro-batches continuamente rodando usando Spark Structured Streaming. Eles não confiaram no checkpointing nativo do Spark ou na semântica de watermark de event-time. O pipeline avançava em progresso de nível de partição em vez de streams de eventos ordenados. A equipe mantinha um watermark lógico externo rastreando a partição processada mais recente por timestamp. O progresso era determinado listando e interpretando dados particionados em armazenamento de objeto, não consumindo um log ordenado.

Duas categorias de falha dominaram o post-mortem. Primeiro, eventual consistency do S3 tornou marcadores de conclusão e padrões de success-file pouco confiáveis como sinais de que uma partição estava pronta para processar. A equipe adotou progresso determinístico baseado em taxa — avançando por tempo em vez de aguardar um sinal explícito de "pronto". Essa abordagem aguantou sob variância de produção. Segundo, semântica de lag e restart exigiu design explícito em vez de herança do framework. Em um pipeline orientado por freshness com semântica de janelas sobrepostas, reproduzir o backlog completo após um restart degradava further a freshness. O fix: pular diretamente para a partição mais recente disponível no restart, tratando estados intermediários perdidos como perda aceitável para recuperação imediata de freshness.

Para arquitetos de dados empresariais, a implicação estrutural é direta. Equipes migrando pipelines batch para streaming frequentemente assumem padrão com Kafka ou um serviço de streaming gerenciado. Este post-mortem argumenta que para pipelines baseados em object-store — que cobrem uma grande parcela da infraestrutura de dados empresariais — essa migração introduz complexidade operacional por registro sem entregar melhoria meaningfully de latência. O scheduling delay, não o modelo de processamento, impulsiona o lag de freshness. Micro-batch sobre object storage existente com gerenciamento explícito de watermark externo fecha essa lacuna enquanto mantém a superfície operacional próxima à infraestrutura batch que equipes já conhecem.

A segunda implicação visa pipelines de ML inference. Equipes canalizando dados de features ou índices de recuperação para endpoints de inferência de LLM enfrentam o mesmo trade-off freshness-vs-complexity. O achado do relatório de que jobs de streaming de longa duração devem tratar restarts como operações normais — não condições de falha — aplica-se diretamente a qualquer job contínuo de feature engineering ou embedding refresh alimentando uma camada de model serving.

Questões abertas permanecem: se a abordagem de watermark externo escala para ambientes multi-tenant onde propriedade de partição é compartilhada, e como a arquitetura interage com o transaction log do Delta Lake quando usado como camada de armazenamento em vez de S3 raw. O case study tem escopo a um pipeline de função fixa. Saini explicitamente nota que as escolhas de design são constraint-específicas.

O takeaway para platform teams: se migração de streaming está estagnada em adoção de Kafka, pode ser porque Kafka não é necessário. Substituir um scheduler por um job micro-batch continuamente rodando e um cursor externo é frequentemente a resposta correta — desde que você design o failure path antes do primeiro incident de produção forçar você a.