Arquitetura dos Dados

Enquanto estudava arquitetura de sistemas distribuídos, uma pergunta começou a me incomodar. Se dois sistemas precisam trocar informações, por que isso costuma ser tão complicado? Parece que é simples, mas talvez não seja tanto. Um sistema gera um dado, o outro o recebe. Mas basta imaginar uma aplicação um pouco maior para perceber que essa comunicação rapidamente se transforma em um problema de engenharia.

Se pensarmos num e-commerce, quando um cliente finaliza uma compra, várias coisas precisam acontecer quase ao mesmo tempo. O estoque deve ser atualizado, o pagamento precisa ser processado, um e-mail de confirmação deve ser enviado, o sistema de logística deve iniciar a separação do pedido, o programa de fidelidade precisa acumular pontos… todas essas informações devem alimentar o Data Warehouse, e talvez um modelo de fraude precise analisar a operação.

E, dependendo da empresa, dezenas de outros sistemas também precisarão saber que aquela compra aconteceu. A pergunta é simples: Como todas essas aplicações descobrem que um novo pedido foi realizado?

Durante muito tempo, a resposta foi conectar tudo diretamente. O sistema de vendas chamava a API do sistema de pagamentos, depois chamava a API do estoque, depois a do CRM, depois a do sistema de e-mails, depois a do ERP, depois a da plataforma de analytics.

Funciona.

Até o momento em que deixa de funcionar.

Quanto mais sistemas são adicionados, maior passa a ser a quantidade de dependências entre eles. O sistema responsável pela venda deixa de cuidar apenas do pedido. Ele passa a conhecer detalhes de todos os outros serviços da empresa. Se o sistema de e-mails ficar indisponível, a venda deve falhar? Se o sistema de recomendações estiver lento, o cliente deve esperar mais tempo para finalizar a compra? Cada nova integração aumenta o acoplamento entre aplicações que, idealmente, deveriam evoluir de forma independente.

Foi justamente esse tipo de problema que levou ao surgimento de plataformas como o Apache Kafka. Curiosamente, Kafka não foi criado para acelerar aplicações, também não foi criado para substituir bancos de dados. Seu objetivo era resolver um problema muito mais específico: permitir que sistemas trocassem informações sem depender diretamente uns dos outros.

A ideia parece simples. Em vez de um sistema enviar informações diretamente para outro, ele apenas publica um evento.

Novo pedido realizado

Quem precisar dessa informação poderá consumi-la.

Quem não precisar simplesmente a ignora.

A comunicação deixa de ser direta e passa a acontecer através de um intermediário.

                Novo Pedido

                     │

                     ▼

             ┌──────────────┐
             │    Kafka     │
             └──────────────┘
              │     │      │
              ▼     ▼      ▼

          Estoque  ERP   Analytics

Esse detalhe muda completamente a arquitetura.

Agora o sistema responsável pelas vendas não precisa mais conhecer quem utilizará aquela informação. Ele apenas publica o evento. Novos consumidores podem ser adicionados amanhã sem que uma única linha do sistema de vendas seja modificada.

Foi nesse momento que comecei a entender por que tanta gente diz que Kafka não é apenas uma ferramenta, é uma mudança na forma de pensar integração entre sistemas.

Outro aspecto que me chamou atenção foi perceber que Kafka não transporta apenas mensagens. Ele constrói uma sequência ordenada de acontecimentos.

Pegando novamente nosso e-commerce.

Pedido criado
↓
Pagamento aprovado
↓
Estoque reservado
↓
Pedido enviado
↓
Entrega realizada

Em muitos sistemas tradicionais, apenas o estado final é armazenado. No Kafka, cada uma dessas mudanças pode existir como um evento independente. Essa diferença parece pequena.

Na prática, ela abre espaço para arquiteturas completamente diferentes. Novos serviços podem reconstruir toda a história de um pedido apenas lendo essa sequência de eventos. Modelos de Machine Learning podem consumir os mesmos dados em tempo real. Pipelines de engenharia de dados deixam de depender de consultas periódicas ao banco. Dashboards passam a ser atualizados continuamente.

Foi justamente aqui que comecei a relacionar Kafka com Engenharia de Dados. Antes eu imaginava que pipelines existissem apenas para mover dados entre bancos, hoje percebo que, cada vez mais, eles nascem dos próprios eventos produzidos pelos sistemas.

O dado deixa de ser extraído e passa a ser publicado no momento em que acontece. Isso reduz latência, simplifica integrações e cria uma arquitetura muito mais flexível. Para quem trabalha com dados, essa mudança é enorme.

Considere este consumidor Kafka extremamente simples.

from kafka import KafkaConsumer
consumer = KafkaConsumer(
    "pedidos",
    bootstrap_servers="localhost:9092"
)
for evento in consumer:
    print(evento.value.decode())

#Pausa pra uma explicação: Consumidor Kafka é uma aplicação que lê eventos publicados no Kafka e executa alguma ação a partir deles. Sigamos!

Enquanto novas compras acontecem, esse consumidor kafka recebe cada evento quase imediatamente. Nenhuma consulta ao banco, nenhum processo executado a cada cinco minutos, nenhuma sincronização manual. Os dados simplesmente chegam.

Naturalmente, essa arquitetura também traz novos desafios. Agora precisamos lidar com ordenação de eventos, processamento distribuído, garantia de entrega, consumidores independentes, retenção de mensagens e consistência entre sistemas.

Kafka não elimina a complexidade, apenas desloca essa complexidade para um lugar onde ela pode ser administrada de forma muito mais eficiente. Talvez essa tenha sido a principal mudança de perspectiva que esse estudo me trouxe.

Durante muito tempo pensei que sistemas trocassem informações através de APIs. Hoje tenho a impressão de que APIs resolvem pedidos, eventos resolvem comunicação.

Essa distinção me parece cada vez mais importante conforme estudo sistemas distribuídos e engenharia de dados como algo interligado. No fim das contas, acho que essa é a verdadeira contribuição do Apache Kafka.

Ele não mudou apenas a maneira como aplicações enviam mensagens umas para as outras, mudou a forma como passamos a enxergar a informação.

Em vez de perguntar “quem precisa receber este dado?”, começamos a perguntar: “Que evento acabou de acontecer?”. E, na minha opinião, essa pequena mudança de pergunta explica por que Kafka se tornou uma das tecnologias mais importantes da Engenharia de Dados moderna.