A Cloudflare recuperou 100TB de RAM em sua infraestrutura global reduzindo o número de pontos de hash em seu algoritmo de consistent hashing e compactando as estruturas de dados que os armazenam em Rust. A otimização veio de análise matemática mostrando que os últimos 90.000 hashes de 100.000 por servidor compravam apenas 0,7% de redução em erro, tornando-os puro desperdício em escala.
O problema começou no Pingora Backend Router, serviço interno de load-balancing da Cloudflare, que usa consistent hashing para rotear requisições cacheáveis para servidores por URL. Consistent hashing mapeia servidores e requisições em uma reta numérica baseada em valores de hash, então atribui cada requisição ao servidor mais próximo. Para lidar com distribuição desigual de carga—um problema que piora conforme a contagem de servidores aumenta—o padrão da indústria é atribuir múltiplos pontos de hash por servidor. A baseline da Cloudflare era 160 hashes por servidor, o mesmo padrão usado em NGINX e adotado por Pingora. Com um fator de ponderação de 625 baseado na capacidade de armazenamento do servidor, o número real implantado era k = 160 × 625 = 100.000 hashes por servidor armazenados em memória.
O time de engenharia da Cloudflare derivou a relação matemática entre contagem de hash e precisão de load-balancing. Segundo seu post, o coeficiente de variação—uma medida de quão desigualmente requisições se distribuem—segue a fórmula CV_k = √((N-1)/(N*k+1)), onde N é contagem de servidores e k é hashes por servidor. Plotar isso mostrou retornos decrescentes: cada aumento de ordem de magnitude em contagem de hash comprava ganhos de precisão progressivamente menores. Mais criticamente, com valores de hash de 32-bit, probabilidade de colisão aumenta entre 10.000 e 100.000 hashes por servidor em data centers com 2048 servidores, introduzindo erros imprevisíveis que o modelo matemático não contabiliza. O time determinou que reduzir contagem de hash em 90% incorreria em nenhum erro apreciável em sua configuração.
A segunda otimização veio de struct packing. A struct Point original armazenava um hash de 32-bit e um índice de servidor de 32-bit como oito bytes. Zaidoon observou que Pingora nunca coordenaria mais de 65.536 servidores, então um índice de 16-bit é suficiente. As regras de alinhamento do Rust normalmente impedem encolher o índice sem encolher a struct, mas armazenar o hash e índice como um array de seis bytes e acessá-los através de métodos getter alcançou o mesmo resultado compilado. Isso reduziu footprint de memória em 25%.
Rolar a mudança exigiu cuidado: trocar hash rings globalmente invalidaria conteúdo cacheado e causaria spike em tráfego de origem. A Cloudflare rodou ambos os rings antigo e novo em memória simultaneamente, roteando requisições para cada um em base por-requisição usando seu framework de migração. Eles rolaram em camadas—pequenas locações de validação primeiro, depois progressivamente data centers maiores—enquanto monitoravam backend-selection traces, uso de memória, comportamento de cache e tráfego de origem. Apenas após atingir 100% de tráfego no novo ring eles descomissionaram o antigo. A queda acentuada de memória no dia de descomissionamento mostrou a recuperação de 100TB.
As técnicas estão disponíveis agora no crate pingora-ketama como um feature flag de Rust, com ambos os rings v1 e v2 rodáveis simultaneamente. Para qualquer time rodando consistent hashing em escala—seja para load balancing, caching ou atribuição de tarefas distribuídas—a lição é medir a contribuição real de cada passo de otimização contra o modelo matemático, então cortar o que não puxa seu peso.