LinkedIn reconstrói infraestrutura de tracking e reduz uso de rede de entrada em cerca de 89%

O Tracking API é a porta de entrada de um pipeline de eventos que o LinkedIn descreve como capaz de processar centenas de bilhões de eventos por dia, com milhões por segundo nos picos e várias centenas de tipos de evento. Os SDKs de mobile e web agrupam as interações em lotes, a camada de borda roteia cada lote para o serviço da categoria certa, e o serviço decodifica, valida, enriquece, classifica, converte e envia os registros ao Kafka pelo produtor assíncrono. O gRPC de sucesso volta assim que o cliente Kafka aceita o registro no buffer local, sem esperar o broker. Por isso, sucesso numa fronteira não prova sucesso na seguinte.

O ganho de rede veio principalmente do contrato novo, que envia o contexto compartilhado de cliente e sessão uma vez por requisição, em vez de repetir em cada evento. Nas janelas observadas, o tráfego de entrada médio caiu de 210,7G para 21,7G (cerca de 89,7%). Como o serviço novo carregava 90% do tráfego, o ajuste para tráfego total deixa a redução perto de 89%. O resultado combina reuso de contexto, Protocol Buffers e outras mudanças de serialização.

A validação usou uma amostra marcada de 10% dos eventos. O pipeline legado seguia gravando no tópico de produção, e o novo escrevia em um tópico sombra, com jobs que casavam os registros por identificador de comparação. Duplicar 100% do tráfego foi descartado pelo custo. Na otimização, a equipe trocou a conversão intermediária para objetos Avro por um encoder inline pré-compilado e passou a compressão do Kafka de gzip para zstd. Em benchmarks locais, o encoder deu 12% a mais de throughput e o zstd 13,7%, mas os ganhos não se somam, e a própria equipe os trata como sinais direcionais, não como capacidade de produção.

Para quem opera pipelines de ingestão, o caso mostra um roteiro reaproveitável: comparar saída com amostra marcada em tópico sombra, migrar por plataforma e categoria com rollback por roteamento, e perfilar sob concorrência real. Também lembra que o gargalo de um serviço ingestor costuma ser CPU, e não I/O, o que muda a escolha de codec e de serialização. A parte sobre transformar falhas tardias do Kafka em backpressure é a que mais interessa a quem usa produtores assíncronos.