Como a Netflix escalou seu mapa de serviços em tempo real

Mapas de dependências desatualizados ajudam pouco durante um incidente. Para resolver esse problema, a Netflix redesenhou o pipeline responsável pelo Service Topology, sistema que mostra as relações entre serviços e permite investigar o caminho real das requisições em produção.

O desafio começa nos dados brutos de rede. Eles registram os saltos percorridos pelo tráfego, mas não representam necessariamente a dependência lógica entre aplicações. Uma requisição pode passar por balanceadores de carga, gateways NAT, gateways de API e proxies antes de chegar ao serviço de destino. O pipeline precisa reconhecer esses intermediários e reconstruir a relação direta entre os serviços envolvidos.

Pipeline dividido em três estágios

A arquitetura foi separada em três estágios, com responsabilidades diferentes. Essa divisão evita concentrar resolução de dependências, enriquecimento de dados e persistência na mesma etapa.

O primeiro estágio consome fluxos Kafka de várias regiões, descarta registros inválidos, agrupa os dados em janelas de cinco minutos e cria agregadores iniciais. O objetivo é organizar o volume recebido e preparar os registros para as etapas seguintes.

O segundo estágio resolve os intermediários da rede. Ele identifica elementos como balanceadores, gateways e proxies, combina os fluxos de entrada e saída e tenta reconstruir o caminho lógico entre a aplicação de origem e a aplicação de destino. Essa etapa exige mais processamento e pode ser afetada por nós que concentram volumes muito maiores que o tráfego normal.

Depois da resolução, os dados são redistribuídos para o terceiro estágio. Essa etapa realiza o enriquecimento, prepara as informações para consulta e persiste o resultado no armazenamento do grafo. A separação permite escalar de forma independente o processamento pesado de resolução e as operações mais relacionadas a entrada e saída.

A estratégia pode ser resumida como distribuir, resolver, distribuir novamente e persistir. Com isso, o volume de trabalho é espalhado entre várias instâncias. Mesmo quando um intermediário recebe tráfego muito acima do padrão, a carga não precisa ficar presa a uma única instância.

Backpressure em vez de descarte

Um dos pontos centrais do desenho é o tratamento da pressão no pipeline. Se o armazenamento do grafo não consegue acompanhar a velocidade de processamento, a aplicação não descarta silenciosamente os registros. A pressão retorna pelas etapas anteriores até chegar ao consumidor Kafka.

O pipeline usa Apache Pekko Streams para controlar o backpressure. Quando a capacidade de processamento diminui, o consumidor pode pausar. Os registros permanecem no Kafka até que o sistema volte a ter capacidade, preservando os dados e evitando que uma sobrecarga temporária se transforme em perda permanente de informação.

Essa decisão troca atualizações mais atrasadas por consistência dos dados. Em um sistema de observabilidade, perder eventos pode produzir uma topologia incompleta e levar equipes a conclusões erradas durante uma investigação. Manter os registros no Kafka permite recuperar o atraso posteriormente.

Por que usar eventos enviados pelo servidor

Para transferir grandes volumes entre partes internas do pipeline, a Netflix escolheu Server Sent Events em vez de gRPC ou filas de mensagens. O modelo mantém um fluxo contínuo de dados em uma conexão, com um mecanismo simples para que o servidor envie atualizações ao consumidor.

A escolha também reduz a complexidade operacional em comparação com uma solução baseada em chamadas individuais. O pipeline pode transmitir os resultados conforme eles ficam disponíveis, sem transformar cada lote em uma sequência de chamadas remotas independentes.

O uso de eventos enviados pelo servidor não é apresentado como uma regra geral para qualquer sistema. Ele atende ao padrão específico do Service Topology, que precisa transportar atualizações contínuas e volumosas entre componentes internos.

Processamento contínuo e latência operacional

A Netflix adotou uma abordagem orientada a streaming, em vez de depender de processos em lote que analisam dados históricos. Os registros de fluxo são consumidos continuamente a partir de streams Kafka distribuídos entre regiões, enquanto métricas de comunicação entre processos são transportadas como eventos enviados pelo servidor.

O resultado esperado é uma visão atualizada em dezenas de minutos, em vez de mapas com horas ou dias de atraso. Essa diferença é relevante durante incidentes. Um mapa antigo pode descrever uma arquitetura que já mudou e dificultar a identificação da dependência responsável pelo problema.

A arquitetura também precisa lidar com crescimento de volume, atraso no Kafka, uso de memória, coleta de lixo, distribuição desigual de carga e depuração de streams reativos. Dividir as responsabilidades ajuda a isolar esses problemas e permite observar cada estágio separadamente.

Lições para sistemas distribuídos

A experiência mostra que escalar um pipeline não significa apenas adicionar instâncias. É necessário separar operações com perfis diferentes, controlar explicitamente o fluxo de dados e escolher onde a pressão deve aparecer quando a capacidade for excedida.

Deixar os dados acumularem no Kafka pode ser melhor que descartar eventos ou deixar a memória das aplicações crescer sem controle. A arquitetura também demonstra a importância de identificar pontos quentes, especialmente quando determinados intermediários concentram uma quantidade desproporcional de tráfego.

Outra lição é que observabilidade precisa representar a arquitetura lógica, não apenas os caminhos físicos observados na rede. Sem resolver os intermediários, o mapa pode mostrar muitos relacionamentos artificiais e esconder a dependência real entre as aplicações.

Como isso pode ser útil para você

Em um sistema Java, Quarkus ou Python que consome eventos, use Kafka como amortecedor e defina o comportamento quando o consumidor ou o banco não conseguir acompanhar a entrada. Prefira pausar o consumo e preservar os eventos a descartar dados silenciosamente.

Também vale separar o pipeline em etapas de ingestão, transformação, enriquecimento e persistência. Essa divisão facilita medir latência, identificar gargalos e escalar apenas o componente que realmente precisa de recursos. Em um projeto pessoal ou produto pago, um mapa de dependências atualizado pode virar uma funcionalidade de diagnóstico para equipes que ainda investigam incidentes com logs isolados.

Antes de escolher gRPC, filas ou eventos enviados pelo servidor, avalie o padrão real de comunicação. Para atualizações contínuas em grande volume, uma conexão de streaming pode ser mais simples que muitas chamadas remotas. O ponto principal é preservar dados, controlar a pressão e entregar uma visão operacional que ainda seja útil quando o incidente estiver acontecendo.

Fonte: https://www.infoq.com/news/2026/08/netflix-service-topology/