Meta corta conexões do ZippyDB em 19 vezes com o proxy ZGateway

A Meta detalhou, em post técnico citado pela InfoQ, a arquitetura do ZGateway, uma camada de proxy stateless criada para resolver um problema que só aparece em escala hiperescala: mais de um milhão de hosts clientes tentando falar diretamente com o ZippyDB, o key-value store distribuído que guarda metadados de produto, contadores e configuração em toda a infraestrutura da empresa. Hoje o ZGateway já processa mais de 1 bilhão de operações por segundo e responde por cerca de 40% do tráfego total do ZippyDB.

O problema: um milhão de hosts batendo direto no banco

No modelo de acesso direto, cada cliente se conecta às réplicas que servem os shards que ele precisa acessar. Como um único cliente pode tocar dezenas de milhares de shards espalhados por centenas de milhares de hosts de banco, o resultado é uma malha de conexões muitos-para-muitos densa demais para escalar de forma segura. A Meta relata que essas "tempestades de conexão" contribuíam para esgotamento de file descriptors e condições de out-of-memory nos servidores.

Esse não é um problema exclusivo de infraestrutura hiperescala. É a mesma dinâmica que qualquer time enfrenta quando escala um serviço com pool de conexões mal dimensionado: cada novo pod ou instância abre suas próprias conexões, e a base de dados vira o gargalo por gerenciar sockets em vez de servir queries.

Como funciona o ZGateway

O ZGateway se posiciona entre clientes e servidores do ZippyDB como um proxy gerenciado. Os clientes mantêm conexões "sticky" com hosts de gateway regionais, enquanto os servidores de banco só recebem conexões vindas da frota controlada de gateways. A descoberta de qual gateway usar acontece via ServiceRouter, o service mesh interno da Meta, o que mantém cada cliente próximo do seu gateway regional.

Internamente, o gateway usa o mesmo cliente C++↳C++6 conteúdosSão Paulo recebe encontro de Programadores C & C++Dev (Back & Front) · mai 2019Melhores linguagens de programação para desenvolver jogosMarketing Tech · nov 2024Desmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Ver tudo em Dev (Back & Front) → do ZippyDB como motor de requisições e suporta dois modos: proxy puro e uma camada de cache read-through. Como o ZGateway enxerga tráfego de múltiplos clientes ao mesmo tempo, ele consegue combinar requisições que bibliotecas cliente isoladas jamais veriam entre processos diferentes, além de autenticar e autorizar requisições, aplicar admission control por tenant, resolver shards e usar cache local antes de repassar tudo para as réplicas do ZServer.

Vale notar que essa arquitetura não substitui o que o ZippyDB já fazia: sharding gerenciado, replicação, detecção de falhas e capacity management continuam sendo responsabilidade do banco. O ZGateway adiciona uma camada compartilhada de gerenciamento de tráfego na frente dessas capacidades, não uma reescrita delas.

Os números que a Meta mediu

O modelo da Meta estima que a contagem de conexões por host caia entre 97% e 98%, e que o total de conexões persistentes na infraestrutura diminua em cerca de 19 vezes. É uma diferença de ordem de grandeza: menos sockets abertos, menos overhead de handshake TLS repetido, menos pressão sobre limites de file descriptor em cada servidor de banco.

Md Shuvo, arquiteto na Sherbrook, resumiu o trade-off em um post no LinkedIn citado pela InfoQ: "Adicionar um hop extra de rede na verdade melhora a latência geral, ao liberar os nós do banco do overhead brutal de gerenciamento de conexões." É contraintuitivo à primeira vista, porque todo dev aprende que menos hops de rede é sempre melhor, mas o ponto é que o custo de manter dezenas de milhares de conexões abertas por host supera o custo de um salto adicional bem dimensionado.

O teste de sobrecarga: quem paga o pato quando falta CPU

A Meta rodou um teste controlado empurrando o ZGateway acima de 90% de uso de CPU. De aproximadamente 1.350 buckets de tenants, apenas seis tiveram tráfego descartado (shed), enquanto os demais processaram 99,9% das requisições sem rejeição. Isso mostra o gateway funcionando como ponto central de proteção contra sobrecarga: em vez de o banco inteiro degradar, o sistema isola o dano a uma fração pequena e previsível de tenants.

O rollout também é controlado com granularidade fina: a Meta pode rotear tráfego progressivamente por serviço, por prefixo de shard, por percentual ou por região, com um kill switch global para reverter tudo de uma vez se algo der errado. Esse tipo de controle de blast radius é o que separa uma migração de infraestrutura crítica bem-feita de uma aposta arriscada.

O que isso muda pra quem constrói com menos tráfego

Ninguém fora da Meta vai operar 1 bilhão de operações por segundo, mas o padrão arquitetural é o mesmo que já existe em ferramentas do dia a dia de quem opera Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, MySQL ou Redis em produção: PgBouncer e PgCat na frente de Postgres, ProxySQL na frente de MySQL, ou um proxy gerenciado como o RDS Proxy da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps →. Todos resolvem exatamente o problema que a Meta descreve, em escala menor: dezenas de pods de Kubernetes escalando horizontalmente e cada um abrindo seu próprio pool de conexões contra o banco, até o banco ficar sem memória para gerenciar sockets em vez de responder queries.

O recorte interessante do ZGateway não é a existência do proxy, mas o que ele agrega além de repassar bytes: batching e coalescing de requisições vindas de clientes diferentes (algo que um pooler simples não faz), admission control por tenant e cache read-through configurável. Para quem projeta um serviço interno com múltiplos consumidores batendo no mesmo dado, vale perguntar se o pooler atual só limita conexões ou também enxerga padrões de acesso entre clientes para economizar round-trips reais no banco.

Usar service mesh (ServiceRouter na Meta, Envoy ou Linkerd em stacks mais comuns) para manter cliente e proxy próximos geograficamente também é replicável: reduz latência de rede e evita que uma região inteira dependa de um gateway do outro lado do mundo.

O que ainda fica em aberto

A Meta ainda não roteia 100% do tráfego do ZippyDB pelo ZGateway, isso é meta declarada, não fato consumado. A empresa também sinalizou que está explorando controles operados por agentes, co-localização seletiva do gateway com o ZServer para reduzir ainda mais a latência, e uma arquitetura multi-processo para isolamento de falhas mais forte. Nenhum desses itens tem cronograma público, e a InfoQ não detalha como o ZGateway se compara em latência absoluta contra o acesso direto fora dos números agregados de redução de conexões.

Fonte: InfoQ