Por que o ZippyDB precisava de um proxy
A Meta revelou o ZGateway, uma camada de proxy que agora fica entre as aplicações clientes e o ZippyDB, o armazenamento chave-valor mais usado dentro da empresa. O ZippyDB sustenta metadados de produtos, contadores e configurações a bilhões de operações por segundo — e é exatamente esse volume que tornou a arquitetura antiga insustentável.
No acesso direto, cada cliente do ZippyDB conectava-se a todos os hosts de banco de dados de que precisava. Um único cliente podia tocar dezenas de milhares de shards espalhados por centenas de milhares de hosts. O resultado: dezenas de milhares de conexões TLS ociosas por host, cada uma consumindo memória, CPU e um descritor de arquivo nos dois lados. Em um incidente, um bug de roteamento fez cada cliente abrir uma conexão por shard, e a frota inteira entrou em loop de reinicialização por exaustão de descritores e falta de memória.
Corrigir do lado do cliente era inviável: a frota é mantida por centenas de times diferentes.
O que o ZGateway faz
O ZGateway é um tier de proxy sem estado entre os clientes e a frota de banco de dados. Segundo a Meta, ele processa mais de 1 bilhão de operações por segundo, carrega cerca de 40% do tráfego do ZippyDB (projeção de passar de 60%) com sobrecarga computacional de apenas ~6% no caso de uso médio.
Na prática, ele é o cliente C++ “espesso” do ZippyDB rodando como serviço gerenciado. Um cliente envia requisições por uma conexão persistente a um host regional do ZGateway, que então termina o TLS, autoriza contra as ACLs do caso de uso, aplica controle de admissão por inquilino, resolve o shard, verifica o cache local, agrupa a requisição com outro trabalho em voo para aquele shard e encaminha para a réplica correta.
A matemática do fan-in
A Meta modela a frota como o problema de “bolas em caixas”: com B shards e H hosts, a probabilidade de um host ser atingido cresce linearmente com o número de clientes no acesso direto. Com o ZGateway, o fan-in passa a depender apenas de regiões × densidade de shards por host — independente das duas frotas. Nos números citados (20 regiões, 500 mil hosts de banco, 30 mil proxies, 1 milhão de clientes), a contagem de conexões por host cai 97 a 98% e o total de conexões persistentes despenca cerca de 19 vezes.
Capacidades que vieram junto
- Migração segura: flags de configuração com ramp percentual, filtro por região e kill switch global.
- Discriminant Load Shedding (DLS): requisições mapeadas em buckets por inquilino e prioridade. Em um teste com CPU acima de 90% em ~1.350 buckets, apenas 6 inquilinos ruidosos perderam carga; os demais executaram 99,9% das requisições com 97-98% de goodput.
- Cache de leitura: leituras quentes servidas em processo, com frescor garantido por eventos de change-data-capture.
- Balanceamento de carga e resiliência cross-region: anéis e mega-regiões que fazem failover para capacidade saudável.
Por que isso importa
O ZGateway não é um pacote que você baixa — o valor está nos padrões. Para quem opera infraestrutura em escala, ele documenta um caminho testado para matar o “connection sprawl”, isolar inquilinos ruidosos e transformar um gargalo linear em uma constante controlável. É uma aula pública de engenharia de sistemas distribuídos vinda de uma das maiores infraestruturas do mundo.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
