Como a Netflix reconstruiu seu mapa de serviços em tempo real para escalar

A Netflix publicou como redesenhou a pipeline de streaming por trás do Service Topology, seu mapa em tempo real das dependências entre serviços, para dar conta da escala de produção. Segundo o relato descrito pela InfoQ, o sistema agora separa a resolução de intermediários do enriquecimento e da persistência em três estágios, propaga backpressure até o Kafka em vez de descartar registros, e adotou server-sent events (SSE) no lugar de gRPC para transferências internas de alto volume.

O que é o Service Topology

O Service Topology combina visões armazenadas separadamente a partir de três fontes: fluxos de rede via eBPF, métricas de comunicação entre processos (IPC) e distributed traces. As equipes podem consultar cada camada isoladamente ou mesclá-las para uma visão mais ampla das dependências. A Netflix afirma que os times usam a ferramenta para investigação de incidentes, análise de blast radius (raio de impacto), entendimento de dependências e gestão de mudanças em produção.

O novo relato foca no caminho de ingestão dos fluxos de rede. O problema central: registros brutos de fluxo mostram saltos de rede, não a dependência lógica entre aplicações. O tráfego pode passar por load balancers, gateways NAT, API gateways ou proxies, mascarando quem realmente conversa com quem.

Os três estágios

Para resolver isso, a Netflix processa os dados em três etapas:

1. Consumo e agregação inicial: lê streams multirregionais do Kafka, filtra registros inválidos, agrupa dados em janelas de cinco minutos e cria os agregadores iniciais.
2. Resolução de intermediários: transforma os saltos de rede em arestas diretas aplicação-para-aplicação e redistribui os resultados.
3. Enriquecimento e persistência: adiciona informações como saúde, propriedade (ownership) e metadados antes de gravar no banco de dados de grafo.

O desenho anterior concentrava trabalho nos destinos populares: como a resolução de intermediários exige juntar fluxos relacionados, destinos muito acessados deixavam instâncias "quentes". A Netflix relata que algumas instâncias chegaram a receber até 100 vezes o tráfego típico enquanto ainda faziam trabalho de enriquecimento pesado em I/O. Separar resolução de enriquecimento e persistência permitiu redistribuir essa carga.

Backpressure em vez de dados perdidos

A pipeline usa Apache Pekko Streams para gerenciar backpressure. Quando o armazenamento do grafo não acompanha, a pressão viaja pelos estágios até o consumidor do Kafka pausar, deixando os registros no próprio Kafka até a capacidade voltar. O resultado é frescor atrasado sob carga em vez de dados descartados ou um mapa incompleto. A Netflix considera isso preferível a mapas gerados em batch que já podem estar desatualizados durante um incidente.

SSE no lugar de gRPC interno

Outra troca notável: a Netflix substituiu o gRPC entre estágios da pipeline por server-sent events. A empresa reporta que serialização, gerenciamento de connection pool e a pressão de memória das respostas em streaming ficaram caros no seu volume. O SSE é descrito como mais leve e compatível com backpressure reativo. Vale a ressalva: esse transporte interno é separado da API gRPC exposta aos clientes do Service Topology.

Escala elástica com hashing consistente

A frota de processamento cresce e encolhe conforme a demanda. Cada instância lê a mesma lista atual de instâncias saudáveis do service registry e usa hashing consistente para decidir qual instância é dona de cada agregador. Quando uma instância entra ou sai, a lista atualizada move automaticamente só os agregadores afetados, sem um processo de rebalanceamento separado.

A pipeline de IPC não precisa dessa etapa extra: suas métricas já descrevem chamadas em nível de aplicação e vêm particionadas por aplicação desde o início.

Reconstrução histórica

Em vez de guardar snapshots completos do grafo ou reprocessar um log de eventos, o Service Topology mantém snapshots de agregadores por janela de tempo e histórico de mutações em nível de propriedade. Com isso, a Netflix diz reconstruir a topologia em um ponto específico no tempo, o que ajuda engenheiros a examinar mudanças de dependências ao redor de um incidente.

Por que isso interessa a quem constrói software no Brasil

As decisões aqui não dependem da escala do Netflix para serem úteis. Separar estágios de processamento por perfil de custo (I/O pesado versus CPU), preferir backpressure a descarte de dados e usar hashing consistente para redistribuir carga sem rebalanceamento manual são padrões aplicáveis a plataformas em crescimento em qualquer contexto, de fintechs a marketplaces. A escolha de trocar gRPC por SSE em transferências internas de alto volume também é um lembrete de que o protocolo "padrão" nem sempre é o mais barato quando o volume aperta.

Fonte: InfoQ