Meta introduced ZGateway, a stateless proxy layer for ZippyDB, its widely used distributed key-value store, to address connection and reliability challenges created by more than one million client hosts. The gateway handles more than 1 billion operations per second and about 40% of ZippyDB traffic, while Meta’s model estimates that the architecture reduces total persistent connections by roughly 19x.
ZippyDB direct access versus ZGateway architecture (Source: Meta Blog Post)
ZippyDB supports product metadata, counters, configuration and other workloads across Meta’s globally distributed infrastructure. In the direct access model, clients connect to the database hosts serving the shards they access. A single client can touch tens of thousands of shards distributed across hundreds of thousands of database hosts, creating a dense many-to-many connection mesh. Meta said connection storms could contribute to file descriptor exhaustion and out-of-memory conditions.
ZGateway places a managed proxy tier between clients and ZippyDB servers. Clients maintain sticky connections to regional gateway hosts, while database servers receive connections from the controlled gateway fleet. ZGateway runs as regional tiers discovered through ServiceRouter, Meta’s hyperscale service mesh solution, keeping clients near their gateway. The gateway uses Meta’s existing C++ ZippyDB client as its request engine and supports both a pure proxy and read-through cache tier. Meta’s model estimates that per-host connection counts fall by approximately 97 to 98%, while total persistent connections decline by roughly 19x.
The change also shifts where shared traffic management occurs. ZGateway can authenticate and authorize requests, apply per-tenant admission control, resolve shards, use local caching, and batch or coalesce requests before forwarding them to ZServer replicas. Because the gateway sees traffic from multiple clients, it can combine requests that individual client libraries cannot observe across processes.
ZGateway request path from client through regional gateway to ZServer replicas (Source: Meta Blog Post)
The proxy pattern is also used in connection poolers, service meshes, CDNs, and API gateways, although their responsibilities and scaling tradeoffs differ. Meta’s earlier description of ZippyDB shows that the database itself already provides managed sharding, replication, failure detection, and capacity management, while ZGateway adds a shared traffic management layer in front of those capabilities.
The additional network hop is a deliberate tradeoff. Md Shuvo, an architect at Sherbrook, highlighted the point in a LinkedIn post:
Adding an extra network hop actually improves overall latency by freeing up database nodes from the brutal overhead of connection management.
ZGateway also provides a centralized location for load balancing, cross-region resilience, caching, and overload protection. In a controlled test above 90% CPU, six of approximately 1,350 tenant buckets shed traffic while the remaining tenants processed 99.9% of requests without rejection. Meta can progressively route traffic by service, shard prefix, percentage, or region, with a global kill switch for rollback.
Meta plans to route all ZippyDB traffic through ZGateway while exploring agent-operated controls, selective co-location with ZServer, and a multi-process architecture for stronger fault isolation.