Esse artigo é uma reescrita de um que escrevi 2 anos atrás. Naquela época estava tentando entender como funcionava esse middleware tão importante em sistemas distribuídos. Depois trabalhei na reestruturação de um sistema bem complexo usando Kafka como base de verdade.
Antes de Entender o que é Kafka, precisamos entender um pouco de Sistemas Distribuídos.
Dentre os padrões de arquiteturas de Sistemas Distribuídos há o Pub/Sub. Quando desenhamos um sistema, ao enviar uma mensagem, há duas questões básicas:
Para quem enviaremos?
Como enviaremos?
Quando usamos APIs REST (ou gRPC) estamos limitados a conhecer o destinatário e enviar para todos os destinatários que estão esperando essa mensagem. Usando um middleware Pub/Sub não precisamos nos preocupar com isso.
Em uma arquitetura Pub/Sub, temos duas perguntas básicas para fazer ao se enviar uma mensagem:
Para quais Tópicos enviaremos essa mensagem?
Qual o formato que será a mensagem?
Pub/Sub é baseado no conceito de Tópico. Tópico é como se fosse um canal, quem subscreve a um Tópico irá receber todas as mensagens enviadas nele. Quem envia a mensagem não sabe quem irá receber, e vice versa! 🧐
Kafka estende o conceito de Pub/Sub ao seu limite. O que de certa forma por o tornar bem mais complexo que seus similares como RabbitMQ, ActiveMQ, ou o SQS/SNS da Amazon.
Com o Kafka você pode:
Configurar o tempo de armazenamento de cada Tópico.
Por padrão o retention.ms de um Tópico é configurado para 604800000 ms (7 dias!)
Criar vários Consumers concorrentes e garantir a forma de funcionamento deles!
Uma Mensagem ser recebida por todos os Consumers
Uma Mensagem ser recebida por apenas um Consumer
Uma Mensagem ser recebida por Consumers Diferentes!
Etc… Com o Kafka qualquer tipo de configuração é possível
Escalonamento fácil.
Fácil de adicionar um novo nó Kafka
Fácil de adicionar um novo Consumer/Producer
Reprocessamento de mensagens
É possível reprocessar todas as mensagens de um Tópico/Consumer específico
Sem Ponto Único de Falha (SPOF)
Criar Streaming de Eventos
Tratar Streaming de Eventos como Base de Dados
Essas duas últimas features são bastantes complexas e não devem ser utilizadas sem muito experimentação prévia.
Há um termo comum que muitos não devem conhecer que é a Burocracia Kafkaniana. Talvez se você é que nem eu, que conhece a literatura de Franz Kafka, mas nunca a leu, só sabe que ele vira uma barata, você não saberá que ele tinha horror a burocracia e que isso está expresso nos livros dele.
Talvez esse nome se refere ao problema que o Apache Kafka resolve. Seu sistema não precisa ser que nem Guichês do Detran, vai de um para outro, para outro… indefinidamente!!!
Se você está construindo um sistema que demandará um nível de complexidade ainda desconhecido, mas já seguro que será bastante complexo. Você pode considerar de usar o Kafka para delegar a responsabilidade de integração de cada serviço.
Com o Kafka, cada serviço deve se preocupar em:
Gerar Eventos
Ouvir os Eventos interessados
Assim há um grande desacoplamento dos serviços. Você pode criar uma Loja virtual que apenas emite um evento de CompraEfetuada gerando assincronamente: