- Data Streaming
- IBM
O que a IBM comprou quando comprou a Confluent
Quase todo mundo equipara Confluent a Kafka. O Kafka é uma de sete peças, e as outras seis explicam por que a IBM pagou onze bilhões de dólares.
Por Archgents · Publicado em 7 de setembro de 2026 · 6 min de leitura
Em 17 de março de 2026 a IBM fechou a compra da Confluent a 31 dólares por ação, um valor de empresa de cerca de onze bilhões de dólares. A Confluent saiu da Nasdaq e passou a ser uma subsidiária da IBM.
A pergunta que nos fazem desde então, em reuniões e no café da manhã executivo que realizamos há pouco, é quase sempre a mesma: se o Kafka é open source e gratuito, o que exatamente a IBM comprou?
A resposta curta é que o Kafka é uma de sete peças. A resposta longa é este artigo.
Confluent não é Kafka com suporte
É a confusão mais comum e a mais cara, porque leva a comparar uma licença contra zero e a concluir o óbvio.
O Kafka resolve um problema: guardar eventos em um log distribuído, ordenado e persistente, do qual muitos consumidores podem ler no seu próprio ritmo e reler o passado quando precisarem. É a peça central e é excelente no que faz.
Mas um backbone de eventos em produção precisa de mais seis coisas, e são justamente essas que uma equipe acaba construindo à mão quando não as compra.
As sete peças
Apache Kafka é o log de eventos. Ordenado, persistente, particionado para escalar na horizontal, com retenção que permite reler o histórico. É a fonte única da verdade sobre o que está acontecendo agora.
Connectors resolve a conexão com o mundo real. Ligar o core, dezenas de bancos de dados e o SaaS da vez ao backbone costuma significar código sob medida, frágil e caro de manter. Aqui são mais de cento e vinte conectores prontos, com captura de mudanças nativa para ler do core sem tocá-lo. É configuração, não desenvolvimento.
Apache Flink processa em tempo real. Os eventos crus raramente servem sozinhos: é preciso uni-los, enriquecê-los e calcular sobre eles no momento, não em uma consulta batch posterior. O Flink SQL torna essa lógica declarativa e versionável, com resultados em milissegundos.
Stream Governance é a peça que a maioria subestima e a que decide se o projeto chega à produção em uma instituição regulada. Sem controle, um backbone de eventos vira um caos de formatos em que ninguém confia. Aqui há um registro de esquemas com contratos versionados, regras de qualidade, linhagem de ponta a ponta, criptografia e controle de acesso.
Tableflow transforma os streams em tabelas Iceberg ou Delta de forma automática. Analítica e IA precisam dos mesmos dados que a operação, e duplicá-los com um ETL noturno é caro, lento e deixa as duas visões fora de sincronia. Um único dado serve às duas.
Cluster Linking replica topics entre clusters, ao vivo. Um único cluster é um ponto único de falha, e cenários híbridos ou multirregião precisam dos mesmos dados disponíveis em vários lugares ao mesmo tempo. Habilita ativo-ativo, recuperação de desastres e a ponte entre on-premise e nuvem sem um ETL no meio.
Confluent Intelligence é a peça mais nova e a que explica o interesse da IBM. Um agente alucina quando lhe falta contexto fresco e confiável do negócio, e não consegue agir sobre o que está acontecendo agora. Essa camada dá contexto ao vivo para o agente e permite que ele execute dentro do próprio fluxo de eventos, sobre dados governados e rastreáveis.
Como uma plataforma assim amadurece
Ninguém começa pela última camada, e tentar isso é o erro mais comum.
- Integração. As conexões ponto a ponto são substituídas por eventos. O objetivo é parar de ter N sistemas falando com N sistemas.
- Backbone de eventos. O log deixa de ser de um projeto e passa a ser da empresa.
- Stream processing. Enriquecer, unir e calcular ao vivo sobre esse backbone.
- Contexto para IA. Os agentes consomem dados governados e em tempo real, e agem sobre eles.
Cada camada habilita mais casos de uso e mais volume sobre a mesma infraestrutura. Microsserviços desacoplados, fraude ao vivo, cliente 360, modernização do core com captura de mudanças, risco e exposição calculados na hora, personalização no momento em que o cliente age. Todos rodam em paralelo sobre o mesmo backbone, sem duplicar a plataforma.
O que a plataforma ganha com a IBM
O comunicado da IBM é claro na sua intenção: a Confluent transmite eventos operacionais ao vivo diretamente para o watsonx.data, para que cada modelo, agente e fluxo de trabalho rode sobre dados corporativos continuamente atualizados. Essa é a tese da compra, e é coerente com a quarta camada acima.
Para quem já opera Confluent, ou está avaliando entrar, é isto que muda na prática.
A plataforma passa a ter a IBM por trás. Onze bilhões de dólares é uma aposta grande e é um sinal. A Confluent deixa de responder a um mercado trimestral e passa a fazer parte do portfólio de dados de uma empresa com décadas de presença corporativa, contratos globais e suporte na região.
O caminho até os agentes fica mais curto. A integração com o watsonx.data é justamente a peça que antes era preciso construir à mão: levar o contexto vivo do negócio até o modelo. Agora vem de fábrica e vem governada.
A base continua open source. Kafka e Flink são projetos da Apache Software Foundation. Isso não mudou com a aquisição e não vai mudar. A arquitetura de eventos que você desenhar é sua e continua portável, e nenhuma decisão corporativa prende você.
Os contratos vigentes seguem o seu curso. Os acordos plurianuais correm até o seu término. A renovação é o momento natural para revisar o roadmap conjunto, e é aí que vale sentar com quem conhece as duas casas.
A liderança de produto subiu de nível. Em agosto de 2026 Jay Kreps, cofundador e criador do Kafka, entregou a direção a Shaun Clowes, até então diretor de produto, hoje gerente geral de Confluent e Dados na IBM. É um bom sinal: o data streaming não virou mais uma linha do catálogo, ganhou cadeira própria na estratégia de dados da IBM.
Por onde começar
A aquisição não muda a análise técnica. As sete peças são as mesmas, o padrão de arquitetura é o mesmo e os casos de uso que ele habilita também. O que muda é que agora há um respaldo maior por trás e um caminho mais curto até os agentes.
É assim que fazemos, e funciona:
- Assessment. Escolhemos um caso de alto impacto, um só. Não um plano de três anos.
- Desenho de arquitetura. Modelamos a solução sobre as peças que o seu caso realmente precisa, nem uma a mais.
- Prova de conceito governada. Na Confluent Cloud, em semanas, com esquemas e linhagem desde o primeiro dia.
Passamos sete anos implementando Confluent na América Latina e hoje somos parceiros IBM. É a mesma arquitetura que vínhamos construindo antes da compra, agora com um parceiro maior por trás.
Fontes: o comunicado de fechamento da operação está no newsroom da IBM, e o anúncio original da aquisição no blog da Confluent.
Os quatro artigos, em um guia para levar
Reunimos o conteúdo do blog em um documento de 16 páginas: por que o lote noturno quebra os agentes, o que a IBM comprou quando comprou a Confluent, o que muda quando o agente executa dentro do fluxo, e como migrar sem parar a operação.
- Os quatro artigos completos, na ordem de leitura, com seus diagramas
- Lista de verificação com quatro perguntas antes de ir para produção
- Escrito a partir de sete anos implementando Confluent na América Latina
PDF · 16 páginas · 519 KB
Preencha os dados e o download começa em seguida.
Outros artigos
Agende uma chamada de diagnóstico gratuita
Com um de nossos arquitetos sênior. Sem venda, apenas contexto.