Apache Kafka: entenda conceitos, arquiteturas e componentes

Neste artigo, busco abordar de forma objetiva e clara conceitos, funcionalidades e alguns exemplos de arquiteturas com o Apache Kafka↳Leia tambémVocê provavelmente não precisa de KafkaDevSecOps · mar 2026. Acredito que o Apache Kafka, nos últimos anos, ganhou uma maior adesão devido à era do Big data↳Big data16 conteúdosResolvendo desafios de Big Data com Ciência de Dados na UberData · abr 2019Segurança “Data-Driven”: como big data e IA estão redefinindo a detecção de ameaças em tempo realDevSecOps · jan 2026USP lança MBA em Inteligência Artificial e Big DataAI · mar 2024Ver tudo em Data → e Data Science. Período em que as empresas, que tradicionalmente utilizavam o cenário de Bussiness Intelligence clássico (ETL), tiveram a necessidade de obter a informação de forma mais rápida, seja pelo crescimento de aplicativos que as empresas dependam hoje para se enquadrarem na concorrência, como mídias sociais, aplicativos mobile e ferramentas auxiliares ou, até mesmo, pelo crescimento da própria empresa onde o trafego de informações do seu sistema principal aumentou consideravelmente. Com isso, as companhias se viram na necessidade de mudar a arquitetura atual para algo mais rápido na captura de informações, que fosse escalável e mais próximo possível de tolerância a falhas.

Durante meus estudos observei adesão recente do Apache Kafka até mesmo por grandes empresas que tinham uma arquitetura de captura de dados, mas de forma “não streaming”. Um exemplo foi a palestra “Do PostgreSQL ao Data Lake utilizando Kafka|Debezium” do Paulo Singaretti no infoQ – Brasil onde ele demostra a evolução da arquitetura do iFood, de um cenário de refinação dos dados de Postgresql/Postgresql, em que era feito um dump da base toda do Postgresql para um cenário de Postgresql com Debezium do Apache Kafka e alimentação de um DataLake.

Brevemente, o que é o Apache Kafka?

O Apache Kafka é uma plataforma de software de código fonte aberto para processamento de fluxo de mensagens escrita em Scala com Java↳Java42 conteúdosNovidades do Java 26 (para desenvolvedores)Dev (Back & Front) · mar 2026Visual Studio Code para Java: o guia completo (dicas, configuração e extensões)Dev (Back & Front) · out 2025Quarkus: Modernizando a linguagem Java para a era da nuvemDev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) →. Entre as vantagens da plataforma podemos enfatizar sua forma de unificar os seus componentes e Plugins externos, baixa latência e alto rendimento se aproximando e muito do Feed de dados em tempo real.

Conceitos que envolvem o Apache Kafka:

Primeiramente, antes de entrarmos mais a fundo sobre o Apache Kafka, devemos entender melhor alguns conceitos que envolvem esta plataforma

• Mensagens – Entenda por mensagens toda a informação que trafega sobre o Apache Kafka, seja uma frase, uma palavra, um array de bytes etc..
• Streaming – O Streaming aplicado nesta plataforma se trata de todo fluxo de uma mensagem até a captura pelo Apache Kafka e o consumo desta mensagem, onde temos o seguinte cenário: Ator -> Ação -> Gera x mensagens, ou seja, um fluxo de pedido por exemplo: Operador de caixa->Criação->Pedido e deste fluxo pode existir uma serie de mensagens.
• Tópico – Um tópico é uma forma de rotular ou categorizar uma mensagem, imagine um armário com 10 gavetas, cada gaveta pode ser um tópico e o armário é a plataforma Apache Kafka, portanto alem de categorizar ele agrupa as mensagens, uma outra analogia melhor sobre o tópico seria tabelas em banco de dados relacionais.
• Producer – O producer ou produtor é quem se conecta a uma plataforma de mensagens e envia uma ou mais mensagens para um tópico especifico.
• Consumer – O consumer ou consumidor é quem se conecta a uma plataforma de mensagens e consome uma ou mais mensagens de um tópico especifico.
• Broker – O conceito de broker na plataforma do Kafka é nada mais do que praticamente o proprio Kafka, ele é quem gerencia os tópicos, define a forma de armazenamento das mensagens, logs etc.
• Cluster – O conceito de cluster é nada mais do que um conjunto de Brokers que se comunicam entre si ou não para uma melhor escalabilidade e tolerância a falhas.
• Log file – Cada tópico armazena seus registros em um formato de log, ou seja, de forma estrutura e sequencial, o log file portanto são os arquivos que contem a informação de um tópico.
• Partitions – As partitions ou partições como o próprio nome disse é a camada de partição das mensagens dentro de um tópico, este particionamento garante a elasticidade, tolerância a falha e escalabilidade do Apache Kafka, portanto cada tópico pode ter varias partições em diferentes localidades.
• Replicas – As replicas são como partições das partições, elas tem o mesmo papel da partição mas como uma forma de redundância de determinada partição, portanto as partições Kafka são altamente disponíveis e replicadas, quando os dados do fluxo são persistentes no Kafka, eles ficam disponíveis mesmo que o aplicativo falhe
• Segmentos – Os segmentos ficam dentro das partições e segmentam as informações contidas nos logs files daquela partição, todo tópico possui sua partição e sua segmentação, a segmentação serve para gerenciar a ordenação da informação do log file bem como o tempo que ela ira ficar persistida.

Estes são os principais conceitos do Apache Kafka devem ser compreendidos, repare que este conjunto de conceitos é o que torna a arquitetura do Kafka escalável, performática e tolerante a falha.

Principais componentes do Apache Kafka.

Agora vamos falar dos componentes do próprio Apache Kafka e também de alguns componentes complementares não obrigatórios de sua arquitetura. Primeiro componente super importante do Apache Kafka é o Zookeeper, todo Broker presente um cluster ou não é mapeado e monitorado pelo Zookeeper, ele é um sistema centralizado desenvolvido pela própria Apache Kafka para manter o controle do status de cada broker e cluster, também faz o controle de cada tópico, partições etc. Eu posso possui um Zookeeper central para um ou mais cluster mas também posso possui um Zookeeper para cada broker ou cluster e eles se comunicam entre si, portanto o Zookeeper é quem garante meu failover caso um cluster venha a falhar.

Ainda falando sobre o ZooKeeper, precisamos abordar sobre o ISR – In Sync Replicas, os tópicos como vimos anteriormente são divididos em partições e cada partição possui suas replicas, como ambos são provenientes de um tópico, existe a eleição dos Leaders que é a partição principal no qual as replicas devem ficar “seguindo” ou replicando os dados, desta forma o Lead é quem serve todas as leituras e armazenamentos de um tópico, o ISR é um serviço dentro do ZooKeeper que acompanha dinamicamente esta eleição dos Leaders e persiste no ZooKeeper, o ISR também possui todas as mensagens confirmadas pelos Leaders ou seja, as mensagens que realmente foram persistidas e desta forma ele pode eleger o Lead com as mensagens mais recentes em um cenário de failover.

Apache Kafka Connect

Agora falando de outro componente presente na plataforma Apache Kafka, o connect é uma ferramenta para transmitir dados de vários tipos de origens para um tópico e de um tópico para vários tipos de destinos:

Ele possui uma interface Rest para gerenciamento dos conectores e possui diversas formas de injeção de dados e de diversas origens, assim como um cluster de brokers o Kafka Connect pode possui um mais em execução e dentro de sua estrutura pode possuir um ou mais workers que são os responsáveis por “pingar” na fonte de dados e realizar o trabalho no qual foi configurado, em um outro artigo pretendo utilizar o Kafka connect para simular a tolerância de falhas, mas de forma geral o Kafka Connect gerencia o deslocamento de injeção dos dados automaticamente com apenas algumas informações que são informadas na sua configuração padrão ou na atribuição de novos connectores através da api rest que é fornecida.

Arquiteturas e cenários:

Diante de tudo que foi abordado anteriormente vamos agora juntar tudo isso e desenhar aqui algumas arquiteturas e discutir a escalabilidade e tolerância a falha para um entendimento melhor como um todo do Apache Kafka.

Na arquitetura acima temos 2 Producers e 3 Consumers, no qual os producers estão se conectando a cada um a um Broker especifico assim como os consumers, temos um Kafka Cluster com o total de 6 Brokers em execução, onde estão divididos em 2 rack de servidores e apenas um Zookeeper para cada conjunto dos 3 Brokers, portanto os brokers 1,2 e 3 estão apontando para o ZooKeeper 1 e os brokers 4,5 e 6 estão apontando para o Zookeeper-3. Até aqui apenas deixamos de forma mais visual o que vimos anteriormente, agora vamos simular alguns cenários e adentrar mais nesta arquitetura.

Cada Producer de nossa arquitetura é na verdade um PDV é um ponto de venda onde foi gerado 3 pedidos por cada producer e enviado a um tópico de Pedidos por exemplo.

Agora configuramos nosso tópico para que ele tenha um total de 3 replicas e 10 partições em cada replica, totalizando um total de 30 Log files.

Realizando a distribuição das partições teríamos algo na pratica parecido com a arquitetura acima, reparem que temos partições do 0 até o 9 pois na prática o Kafka distribui iniciando em 0 e observe também que existe Brokers com as mesmas partições, por exemplo a partição 0 que esta presente no Broker 1,2 e 3 isso se deve ao nosso fator de replica ser 3.

Agora vamos ver como fica a questão dos Leaders e os followers dos Leaders

Observe na imagem acima que foi distribuido as partições leaders de cada Broker e seus Followers (demais replicas), portanto por exemplo do Rack 1 – Broker 0 temos dois Leaders definidos Partição 0 e 6 e suas replicas são a partição 5 e partição 4, apenas lembrando que quem controla esta lista de Leaders e Followers é o ISR – In Sync replicas.

A forma como é distribuído as partições não é aleatória, o Apache Kafka distribui seguindo uma forma de loterancia a falha de acordo com o a arquitetura de todo o Cluster, onde caso uma partição Leader fique offline outra ja é definida. Importante também frisar a importância da localização dos Racks, em nosso caso como possuímos 2 racks, a distancia entre eles não pode ser grande, pois conforme evidenciei nas arquiteturas acima, existe partições de Broker em outro Rack e caso a região seja distante ou seja, caso exista problemas de rede, pode ser que se tenha uma latência e dependente das configurações do seu Zookeeper e ISR pode ser considerado que o determinado broker esteja offline devido ao timeout de resposta e seja elegido outro Leader.

Conclusão

O Apache Kafka vem tendo uma adotação rápida no mercado e muito se tem falado sobre diante dos cenários de Big data e Data Science, devido a sua escalabilidade e tolerância a falha o Kafka é ideal para trabalhar com integrações de sistemas através de mensagens em tempo real e também ser utilizado como um grande centralizador para os diversos sistemas que existir em sua companhia ou projeto, no entanto é de grande importância um bom desenho da sua arquitetura e configurações visto sua grande complexidade.

Referências:

• Livro Apache Kafka, autor – Nishant Garg.
• Livro Kafka Streams – Real-time Stream Processing, autor – Prashant Kumar Pandey.
• Documentação Confluent.io

Artigo original publicado nas redes sociais do autor e republicado no iMasters a pedido do autor.