// stack.lumi

Dados

Kafka

Eventos em tempo real para dados e sistemas distribuidos.

// o que é

Apache Kafka e uma plataforma de streaming de eventos usada para integrar sistemas e processar dados em tempo real. Na Lumi Data, Kafka entra quando decisoes, alertas ou produtos dependem de baixa latencia.

O Apache Kafka foi concebido a partir do insight de Jay Kreps (2013) de que um log imutável e distribuído é a abstração unificadora de sistemas de dados — tanto para mensageria quanto para replicação de banco de dados, CDC (Change Data Capture) e event sourcing. Essa perspectiva antecede a formalização do padrão CQRS (Command Query Responsibility Segregation) por Fowler e Young (2005), mas converge com ele: ao separar escrita de eventos de consulta de estado, o Kafka permite que cada consumidor mantenha sua própria visão materializada dos dados. Kleppmann (2017) trata o Kafka como o exemplo canônico de log-based message broker, distinguindo-o de filas tradicionais pela retenção de mensagens e replay soberano pelo consumidor. O teorema CAP (Brewer, 2000) é central para entender os trade-offs de Kafka: ele prioriza disponibilidade e tolerância a particionamento, aceitando consistência eventual — o que torna crítico entender garantias de entrega (at-most-once, at-least-once, exactly-once) antes de adotar.

Como a Lumi enxerga:A Lumi desenha topicos, contratos de evento, consumidores, retencao e observabilidade para evitar streaming caotico e caro.

// na prática

Como empresas usam Kafka

Banco digital com detecção de fraude e alertas em tempo real

Transações são publicadas como eventos no Kafka com latência abaixo de 100ms; consumidores paralelos aplicam modelos de ML para scoring de fraude, atualizam limite disponível e disparam notificações push — tudo antes do retorno da resposta ao cliente. O Kafka serve como backbone de integração entre sistemas de core banking, antifraude e notificações sem acoplamento direto, permitindo que cada sistema evolua independentemente sem quebrar o fluxo de eventos.

Plataforma de e-commerce com CDC de banco transacional para data lakehouse

Kafka Connect com conector Debezium captura todas as mudanças no MySQL de produção como eventos CDC, publicando-as em tópicos que alimentam tanto o Redshift em quase-tempo-real quanto o Delta Lake para histórico. Isso elimina o ETL batch noturno que causava discrepância de até 24 horas entre o sistema transacional e o BI, e permite que analistas consultem dados de ontem com granularidade de transação individual.

Empresa de logística com rastreamento de frota e otimização de rotas

Dispositivos GPS de 30 mil veículos publicam posição a cada 30 segundos em tópicos Kafka; Flink Streaming consome esses eventos para detectar desvios de rota, calcular ETAs dinâmicos e alimentar o painel de controle de operadores em tempo real. A retenção configurável do Kafka permite reprocessar o histórico de posições para treinar modelos de previsão de atrasos sem depender de um sistema de armazenamento separado para os dados brutos.

// decisão técnica

Quando usar — e quando não usar

Use quando

Há necessidade de integrar múltiplos sistemas produtores e consumidores de eventos sem acoplamento ponto a ponto — Kafka atua como hub central que desacopla produtores de consumidores.
O volume de eventos é alto (centenas de milhares por segundo) e a escala horizontal é necessária; a arquitetura de partições do Kafka permite distribuir carga sem gargalo de escrita.
O caso de uso exige replay de eventos: auditoria de fraude, debugging de integração, reconstrução de estado ou retreinamento de modelos com dados históricos de eventos.
A empresa adota CDC para replicar mudanças de bancos transacionais para sistemas analíticos ou outras bases, eliminando ETL batch pesado com Kafka Connect e Debezium.
A arquitetura é orientada a eventos e múltiplos microsserviços precisam reagir ao mesmo evento (ex: pedido criado) de forma independente sem chamadas síncronas entre si.

Evite quando

O volume de mensagens é baixo (menos de alguns milhares por hora) e a latência de segundos ou minutos é aceitável; SQS, Pub/Sub ou até um banco de dados com polling resolvem com infinitamente menos complexidade operacional.
O time não tem nenhuma experiência com sistemas distribuídos e a empresa não tem budget para Confluent Cloud ou MSK gerenciado; Kafka auto-gerenciado em produção é operacionalmente custoso e propenso a incidentes de configuração incorreta.
O caso de uso é simplesmente enviar um e-mail ou notificação em resposta a um evento; um serviço de fila simples ou Cloud Functions é suficiente e não exige o modelo mental de log distribuído.
A empresa está no estágio inicial e ainda não tem clareza sobre os fluxos de eventos do negócio; adotar Kafka prematuro resulta em tópicos mal nomeados, schemas inconsistentes e debt de arquitetura difícil de corrigir depois.

// visão lumi

Na Lumi, Kafka é uma decisão arquitetural séria — não uma escolha de ferramenta. Antes de recomendar, mapeamos os fluxos de eventos do negócio, o volume real por segundo, e quem são os produtores e consumidores. A maioria das empresas que "quer Kafka" na verdade precisa de uma fila de mensagens mais simples ou de CDC bem configurado. Quando Kafka faz sentido, preferimos Confluent Cloud ou serviços gerenciados (MSK, Event Hubs) para eliminar o trabalho operacional de Zookeeper e brokers, e exigimos Schema Registry desde o primeiro dia — sem contratos de schema, tópicos Kafka viram acoplamento implícito disfarçado de desacoplamento.

Lumi escolhe quando

Quando o volume de eventos supera dezenas de milhares por segundo e a escalabilidade horizontal de partições é necessária para sustentar o crescimento.
Quando múltiplos times ou sistemas precisam consumir o mesmo fluxo de eventos de forma independente, justificando o modelo de log distribuído.
Quando há requisito de CDC para replicação de banco transacional para destinos analíticos ou de integração, com Debezium como conector.
Quando a empresa adota arquitetura orientada a eventos com microsserviços e precisa de um backbone de integração que não crie acoplamento direto entre serviços.

Lumi não recomenda quando

Quando o caso de uso é troca simples de mensagens entre dois sistemas e uma fila gerenciada (SQS, Pub/Sub) resolve com menos custo e complexidade.
Quando o time não tem maturidade em sistemas distribuídos e não há budget para serviço gerenciado — Kafka mal operado em produção é fonte de incidentes recorrentes.
Quando a empresa ainda não mapeou os eventos do negócio; adotar Kafka antes de ter clareza de domínio resulta em arquitetura de eventos que ninguém entende depois.

// aplicações

Onde essa tecnologia gera valor

CDC e integracao entre sistemas

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Fraude, risco e alertas em tempo real

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Arquiteturas event-driven

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Pipelines de streaming para data lakehouse

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

Kreps, J. (2013). The Log: What every software engineer should know about real-time data's unifying abstraction. LinkedIn Engineering Blog. https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

Artigo seminal que fundamenta o Kafka como implementação do log imutável como abstração universal de integração de sistemas.

Narkhede, N., Shapira, G., & Palino, T. (2017). Kafka: The Definitive Guide. O'Reilly Media.

Referência técnica completa de Kafka, cobrindo arquitetura, producers, consumers, Connect, Streams e operações em produção.

Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.

Capítulo sobre stream processing e log-based message brokers; contextualiza Kafka entre filas tradicionais e sistemas de stream processing.

Brewer, E. A. (2000). Towards robust distributed systems. Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (PODC).

Teorema CAP que fundamenta os trade-offs de consistência e disponibilidade presentes em qualquer decisão de arquitetura com Kafka.

Fowler, M., & Young, G. (2005). CQRS. martinfowler.com. https://martinfowler.com/bliki/CQRS.html

Padrão CQRS que complementa event sourcing com Kafka, separando fluxos de escrita de evento e leitura de estado materializado.

// tecnologias relacionadas

Dados

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.

Avaliar meu stack →Voltar ao stack