Event Streaming: processando eventos contínuos em tempo real

O que é event streaming e como difere de message queues

A evolucao de filas para streams contínuos

Event streaming é um paradigma onde eventos sao armazenados como um log imutável e contínuo, que pode ser consumido por múltiplos sistemas de forma independente, inclusive reprocessando o histórico a qualquer momento. Diferente de message queues tradicionais, onde mensagens sao deletadas após o consumo confirmado, sistemas de streaming como Kafka retêm eventos por um período configurável, permitindo que novos consumers iniciem do começo do log. Essa diferenca fundamental muda como sistemas distribuídos sao projetados: em vez de comunicacao ponto-a-ponto, o stream funciona como fonte de verdade compartilhada que diferentes sistemas consomem ao seu próprio ritmo. Event streaming é o alicerce de arquiteturas event-driven modernas em larga escala.

Eventos como log imutável — reprocessamento e replay

O poder de poder voltar ao passado

Em sistemas de event streaming, cada evento é um fato imutável que descreve algo que aconteceu: "pedido criado", "pagamento confirmado", "estoque atualizado". Ao contrário de mensagens de comando que representam intencoes, eventos representam fatos consumados e por isso nunca devem ser modificados ou deletados antes de sua expiração de retenção. A capacidade de replay é o que diferencia event streaming de qualquer outro mecanismo de comunicacao assíncrona: se um novo serviço entra no ar ou um bug é corrigido, é possível reprocessar todos os eventos desde o início para construir o estado correto. Essa propriedade elimina a necessidade de migrações de dados complexas em muitos cenários, substituindo-as por simples reprocessamento do stream histórico.

Event sourcing — construindo estado a partir de eventos

O banco de dados como derivado dos eventos

Event sourcing é um padrão arquitetural onde o estado atual de uma entidade é derivado aplicando todos os eventos relacionados a ela em ordem cronológica, em vez de armazenar diretamente o estado atual. O event store é o único repositório de verdade: tabelas relacionais ou documentos MongoDB passam a ser projecoes derivadas dos eventos, regeneráveis a qualquer momento. Um agregado Pedido, por exemplo, é reconstruído aplicando PedidoCriado, ItemAdicionado, PagamentoConfirmado e PedidoEnviado em sequência. Event sourcing tem trade-offs significativos: queries complexas sobre o estado atual requerem projecoes materialisadas, e a evolucao do schema de eventos precisa de estratégias de versionamento cuidadosas como upcasting.

CQRS com event streaming

Separando leitura de escrita para escala independente

CQRS (Command Query Responsibility Segregation) é frequentemente combinado com event streaming: comandos modificam o estado gerando eventos, e projecoes consomem esses eventos para construir read models otimizados para queries. Essa separacao permite escalar o lado de leitura independentemente do lado de escrita, e usar modelos de dados diferentes para cada um. O write model pode ser um event store normalizado, enquanto o read model pode ser um documento desnormalizado no MongoDB otimizado para as queries mais frequentes da aplicacao. A consistência entre write e read models é eventual: há um intervalo de tempo entre a publicacao do evento e a atualizacao da projecao, o que deve ser comunicado explicitamente na UX da aplicacao.

Windowing — agregacoes em janelas de tempo

Calculando métricas sobre streams contínuos

Windowing é a técnica de agrupar eventos em janelas temporais para calcular agregacoes como contagens, somas e médias. Tumbling windows dividem o tempo em períodos fixos e nao sobrepostos (ex: métricas por minuto completo). Sliding windows avancam continuamente, produzindo resultados a cada novo evento considerando os últimos N segundos. Session windows agrupam eventos relacionados separados por períodos de inatividade. Calcular "número de tentativas de login nos últimos 5 minutos" é um exemplo de sliding window usado para deteccao de brute force. Sistemas como Kafka Streams, Apache Flink e Spark Structured Streaming oferecem APIs de windowing com suporte a late-arriving events, onde eventos chegam fora de ordem e precisam ser inseridos na janela correta retroativamente.

Processamento stateful vs stateless

Quando o contexto importa no processamento

Processamento stateless transforma eventos individualmente sem depender de eventos anteriores: filtrar, enriquecer com dados externos ou converter formato sao exemplos. Processamento stateful mantém contexto acumulado entre eventos: contar sessoes ativas, detectar padroes de comportamento ou calcular médias moveis requerem estado persistido entre eventos. Em sistemas de streaming, o estado é tipicamente armazenado localmente em cada instancia do processador (ex: RocksDB no Kafka Streams) com changelog persistido no próprio Kafka para tolerância a falhas. O desafio do processamento stateful é o reparticionamento: quando novas instancias sao adicionadas ou removidas, o estado precisa ser redistribuído ou reconstruído a partir do changelog, gerando latência temporária.

Apache Flink para processamento complexo

O framework de streaming mais maduro do mercado

Apache Flink é um framework de processamento de streams e batch que oferece garantias de exactly-once, processamento baseado em event time (usando o timestamp do evento, nao da chegada), e suporte a late events com watermarks configuráveis. Flink processa eventos com latência de milissegundos mesmo em estados de terabytes, distribuindo o processamento em clusters com centenas de nós. O modelo de programacao baseado em DataStream API ou Table API (SQL) permite expressar transformacoes complexas com estado de forma declarativa. Flink é a escolha dominante para casos que exigem processamento stateful complexo em escala, como deteccao de fraude em tempo real, analytics de clickstream e pipelines de dados críticos onde a precisao semântica de event time é obrigatória.

Exactly once semantics em streams

A garantia mais difícil de entregar em sistemas distribuídos

Exactly-once semantics garante que cada evento seja processado exatamente uma vez, mesmo em presenca de falhas e reprocessamentos. Sistemas como Kafka com transacoes e Flink com checkpointing conseguem essa garantia end-to-end, mas com overhead de latência e throughput. At-least-once (pelo menos uma vez) é mais fácil de implementar e suficiente quando o processamento é idempotente — executar a mesma operacao múltiplas vezes com o mesmo resultado. At-most-once (no máximo uma vez) é inadequado para dados críticos pois admite perda de eventos em falhas. A escolha da semântica de entrega deve ser consciente: exactly-once em sistemas de pagamento é obrigatório, enquanto at-least-once em sistemas de analytics tolerantes a duplicata oferece throughput significativamente maior.

Data pipelines com streaming

Substituindo ETL batch por fluxo contínuo

Pipelines de dados tradicionais processam dados em batch: extraem de uma fonte, transformam e carregam no destino periodicamente (hourly, daily). Streaming pipelines eliminam essa latência processando dados continuamente assim que chegam, tornando o data warehouse sempre atualizado. Ferramentas como Kafka Connect com CDC (Change Data Capture) capturam mudancas em bancos de dados relacionais como eventos do Kafka, que fluem para transformacoes em tempo real antes de serem carregados no destino. Essa arquitetura reduz a janela de dados desatualizados de horas para segundos, habilitando casos de uso como deteccao de anomalias em tempo real, recomendacoes personalizadas com comportamento recente e dashboards operacionais que refletem o estado atual do negocio.

Conclusao — event streaming como paradigma fundamental

Adotando streaming onde faz sentido

Event streaming nao é a solucao para todos os problemas: a complexidade operacional e a curva de aprendizado sao maiores que sistemas de filas tradicionais. Mas para casos que exigem reprocessamento histórico, múltiplos consumidores independentes, analytics em tempo real ou event sourcing, streaming oferece uma base arquitetural que nenhuma outra tecnologia consegue substituir. Continue em: Fundamentos obrigatórios antes de produção.