Tutorial Kafka para Iniciantes | Tudo o que você precisa para começar

A construção de aplicações modernas, como um e-commerce com múltiplos microsserviços para pagamentos, pedidos e estoque, gera uma complexa cadeia de eventos. Quando um pedido é finalizado, uma reação em cascata é disparada, exigindo atualizações em diversos sistemas, como o envio de notificações, a geração de faturas e o registro de dados de vendas no dashboard.

Em uma arquitetura inicial e simples, os microsserviços se comunicam diretamente, forçando uma dependência síncrona. Essa abordagem se torna um pesadelo quando o volume de tráfego aumenta drasticamente, como durante promoções de grande escala. A lentidão ou falha de um único serviço paralisa todo o processo de pedido, resultando em telas de carregamento para os usuários e perda imediata de receita.

Nossa arquitetura que parecia limpa no quadro branco se torna um pesadelo.

Para resolver a instabilidade, a solução proposta é redesenhar o sistema para que os pedidos fluam como itens em uma esteira transportadora, e não como um jogo de batata quente. Isso é alcançado removendo o acoplamento direto e introduzindo uma ferramenta intermediária que atua como um broker, criando um espaço entre os serviços.

O Kafka assume o papel de um serviço de correio central. Em vez de os vendedores entregarem pacotes diretamente ao cliente, eles os entregam ao correio. Da mesma forma, o serviço de pedidos entrega um pacote, chamado evento, ao Kafka, informando que um pedido foi feito, e segue seu trabalho sem esperar pela confirmação de que as outras ações foram executadas.

Um evento possui uma estrutura simples, composta por um par chave-valor e metadados. O serviço que gera e envia esse evento ao Kafka é denominado produtor. Este produtor confia no broker para garantir a entrega correta às partes interessadas, liberando-o imediatamente da tarefa.

Os eventos de diferentes produtores (como pedidos, pagamentos e estoque) não são despejados em um único local. Para manter a performance, o Kafka utiliza tópicos para agrupar eventos do mesmo tipo, como um tópico 'orders' ou um tópico 'payments'. O engenheiro define a estrutura desses tópicos, análogo à definição de um schema SQL.

No lado oposto, os consumidores são os microsserviços que se inscrevem nos tópicos de interesse. Quando um novo evento é adicionado, todos os consumidores inscritos são notificados pelo Kafka. Por exemplo, o serviço de notificação lê o evento de pedido para enviar um e-mail, enquanto o serviço de estoque atualiza o banco de dados e pode, por sua vez, gerar um novo evento para o tópico de inventário.

A questão se o Kafka substitui um banco de dados é comum, visto que ele armazena dados como eventos e atualiza status. A resposta direta é negativa. O Kafka não é um repositório de estado primário, mas sim um facilitador de fluxos de trabalho complexos baseados em eventos.

Um uso crucial reside na criação de reações em cadeia. Após o serviço de inventário atualizar o banco de dados, ele produz um evento para o tópico de inventário. Outro serviço pode consumir esse evento para verificar se o estoque de algum produto caiu abaixo do limiar mínimo, o que, por sua vez, aciona um serviço de reabastecimento para encomendar mais itens.

Um caso de uso extremamente importante para o Kafka é a análise em tempo real. Dashboards de vendas são atualizados instantaneamente com cada transação, e aplicações como Uber dependem do envio constante de atualizações de localização dos motoristas para manter a interface do usuário sincronizada com a realidade.

O Kafka utiliza a Stream API para gerenciar esses fluxos contínuos. Consumidores regulares processam um evento por vez, como um serviço de notificação lendo um evento de pedido para enviar um e-mail. Em contraste, as Streams processam o fluxo contínuo de dados, permitindo agregações e junções para realizar processamento analítico em tempo real.

Com milhões de usuários gerando dezenas de milhares de eventos por segundo, a escala de escritas e leituras se torna um desafio de performance. O conceito de partição é fundamental para a capacidade de escalabilidade do Kafka, tornando o processamento de grandes volumes de dados gerenciável sem comprometer a velocidade.

As partições são análogas a adicionar mais trabalhadores a seções específicas de um escritório de correios. Em vez de uma fila única, o tópico é dividido. Por exemplo, no tópico de pedidos, podem ser criadas partições para pedidos da Europa, dos EUA e da Ásia. O engenheiro define essa estrutura de particionamento como parte do design do schema.

Embora as partições permitam que produtores escrevam em paralelo, é necessário escalar os consumidores para lidar com o volume de dados. Se um único serviço de inventário tentar processar todos os eventos, ele ficará sobrecarregado, mesmo com as partições distribuídas.

Os grupos de consumidores resolvem esse problema. Ao iniciar instâncias adicionais do mesmo microsserviço (réplicas), elas se agrupam usando o atributo 'groupID' ao se registrarem no Kafka. O Kafka então distribui automaticamente as partições entre os consumidores ativos desse grupo, permitindo o processamento paralelo e aumentando a taxa de consumo.

Os dados armazenados nos tópicos são fisicamente salvos nos servidores do Kafka, conhecidos como Brokers. Cada broker funciona como uma filial do correio, responsável por armazenar as mensagens no disco, gerenciar requisições de produtores e consumidores, e replicar os dados para garantir tolerância a falhas.

A principal distinção entre o Kafka e brokers de mensagem tradicionais reside na persistência. Brokers convencionais deletam mensagens assim que são consumidas. O Kafka, por outro lado, persiste cada evento conforme uma política de retenção configurável, permitindo que consumidores leiam os mesmos dados múltiplas vezes, o que é vital para análises de longo prazo.

Essa capacidade de processar fluxos de dados em tempo real mantendo os dados originais para análise posterior é o que realmente diferencia o Kafka.

Essa diferença é comparável à escolha entre assistir a um programa de TV pré-agendado (broker tradicional) e assistir sob demanda no Netflix (Kafka), onde o espectador controla o ritmo, a pausa e a possibilidade de rever o conteúdo.

O Kafka requer um mecanismo para rastrear quais brokers estão ativos, eleger líderes e gerenciar a configuração do cluster. Tradicionalmente, essa coordenação era delegada a uma ferramenta externa chamada Zookeeper, que funcionava como um gerenciador central para todos os brokers.

No entanto, versões mais recentes do Kafka, a partir da versão 3.0, introduziram o KRaft (Kafka Raft). Esta implementação integra a funcionalidade de coordenação diretamente no próprio Kafka, eliminando a necessidade de manter o Zookeeper como uma dependência externa e centralizando o controle dentro da infraestrutura Kafka.