Como a engenharia da Zalando escalou o balanceamento de carga no lado do cliente para 1 milhão de RPS

Skipper é um roteador HTTP e controlador de ingresso Kubernetes desenvolvido pela Zalando em Go, projetado para composição de serviços, não como balanceador genérico, mas como uma ferramenta de roteamento inteligente com suporte nativo a consistent-hash, proteção contra sobrecarga e fade-in controlado Skipper no GitHub. Ele funciona bem na borda, mas sua natureza compartilhada e global tornou-se um gargalo para tráfego interno de alta fan-out, como o da Product Read API (PRAPI), onde cada requisição em lote de 100 produtos gerava 100 chamadas individuais passando por Skipper, multiplicando latência, obscurecendo causas de falhas e impedindo visibilidade real de comportamento do serviço.

O novo client-side load balancer da Zalando não é um substituto genérico, mas uma implementação JVM *específica* para o caso crítico de PRAPI. Ele replica exatamente o algoritmo de hash ring do Skipper (xxHash64 com 100 nós virtuais), garante paridade absoluta de roteamento durante migração e opera dentro do processo, sem dependências externas além do JDK, Micrometer e um cliente Kubernetes watch-based. Isso elimina o salto de rede, remove o ponto único de falha compartilhado e dá controle total sobre sinais de carga, como a métrica de *occupancy* (trabalho em segundos por segundo), que revelou desequilíbrios reais escondidos por contadores de requisições em voo.

A cobertura CEVIU de 25/06/2026 já detalhava a existência do novo balanceador in-process e sua capacidade de 1 milhão de RPS. O que mudou agora é a divulgação técnica completa do *como*: a implementação concreta da N-ring fade-in (não apenas 'fade-in', mas múltiplos anéis imutáveis com curvas independentes), a troca definitiva do sinal de carga de *in-flight requests* para *occupancy*, e a confirmação de que a migração foi feita com fallback transparente e toggles granulares, não como experimento, mas como operação estável em produção com impacto mensurável em custo (redução de 50 para 8 pods no Skipper) e resiliência.

Para devs brasileiros que lidam com microsserviços em Kubernetes, essa arquitetura mostra que client-side load balancing não é só sobre performance, é sobre *propriedade*. Ao tirar o roteamento do caminho crítico compartilhado, a equipe ganhou diagnóstico preciso, reduziu dependência de infraestrutura centralizada e pôde otimizar sinais de carga com base no tempo real de processamento, não em contagens superficiais. Isso eleva a DX porque os engenheiros passam a medir o que realmente importa: quanto tempo um pod está ocupado servindo, não quantos requests estão pendentes. E isso muda decisões de escalonamento, cache e até design de APIs.