LinkedIn inova na arquitetura de dados com Northguard e Xinfra para superar gargalos do Kafka

Em face das demandas de escala extremas, o LinkedIn, berço do Apache Kafka em 2010, desenvolveu internamente o Northguard e o Xinfra. Essa nova arquitetura visa superar gargalos que o próprio Kafka, fundamental para o processamento de 32 trilhões de registros e 17 PB diários da plataforma até 2025, começou a apresentar em um cenário de volume tão massivo. O principal desafio estava no acoplamento das funcionalidades de ordenação, replicação e posicionamento de dados em uma única partição Kafka, tornando a movimentação e recuperação de informações custosas.

O Northguard desacopla essas responsabilidades, introduzindo segmentos como unidades menores de replicação, o que permite realocar dados de forma mais granular e distribuir o tráfego de maneira mais eficiente. Complementarmente, o Xinfra atua como uma camada de virtualização, isolando as aplicações das complexidades da infraestrutura subjacente. Isso garante uma transição transparente e fluida para os milhares de serviços do LinkedIn que já utilizavam clientes Xinfra, movendo tópicos entre sistemas físicos ou entre Kafka e Northguard sem impactar a operação. Esta abordagem técnica permite que o LinkedIn continue a inovar em dados, como vimos em nossa cobertura sobre o uso de Kafka em suas integrações unificadas e escalando sistemas de ranking com LLMs, mantendo sua capacidade de resposta e consistência.

O que era uma solução de ponta que o próprio LinkedIn criou e popularizou globalmente, o Kafka, agora enfrenta suas próprias limitações para a escala da empresa. Nossa matéria de 12 de março de 2026, "Impulsionando a melhoria de dados e o sucesso no recrutamento com as integrações unificadas do LinkedIn", mostrava o Kafka como um pilar da arquitetura da plataforma. Agora, com o Northguard e o Xinfra, o LinkedIn não apenas demonstra a capacidade de ir além das ferramentas existentes, mas também a viabilidade de reescritas complexas de infraestrutura, mantendo a compatibilidade.

A evolução aqui é que o LinkedIn, que uma vez usou o Kafka como a espinha dorsal para streaming e orquestração de dados, agora o está aprimorando com soluções internas que abordam os problemas que surgem em suas dimensões únicas. Enquanto outras grandes empresas, como a Atlassian, migram para Kafka para gerenciar bilhões de eventos, conforme noticiamos em 30 de julho de 2026, o LinkedIn mostra um caminho de inovação para as fronteiras extremas do processamento de dados.

A iniciativa do LinkedIn é um estudo de caso fundamental para engenheiros de dados e arquitetos, ilustrando que mesmo tecnologias consagradas como o Kafka possuem limites em escalas hiperelevadas. A solução não é simplesmente "trocar" de tecnologia, mas redesenhar os fundamentos. O Northguard, ao separar a lógica de armazenamento e replicação, e o Xinfra, ao virtualizar a camada de acesso, fornecem um blueprint para outras organizações que enfrentam desafios similares.

Isso mostra que a complexidade não desaparece, mas é realocada para a equipe de plataforma, que agora gerencia sistemas como MySQL, ZooKeeper, Vitess e Couchbase para suportar o Xinfra. A decisão de manter o armazenamento em discos locais com Direct I/O e um cache gerenciado por aplicação, ao invés de adotar uma abordagem de "Kafka Sem Disco" em object storage como discutido em 15 de setembro de 2026, é crucial para as necessidades de baixa latência do LinkedIn e oferece uma perspectiva diferente para projetos de dados em escala.