Meta introduces ZGateway proxy to unify and control traffic to ZippyDB

Meta introduced ZGateway as a stateless proxy tier placed between ZippyDB clients and the ZServer fleet. It is designed to unify all client traffic through a single managed layer. The proxy can process more than one billion operations per second and currently handles about forty percent of ZippyDB’s total traffic. Projected growth expects the proxy to carry beyond sixty percent of the load.

Before ZGateway, each ZippyDB client opened connections to every database host it needed, creating a dense many-to-many mesh of TLS links. A typical client held tens of thousands of outbound connections while each host accepted tens of thousands inbound. This mesh consumed memory, CPU and file descriptors on both ends, mostly while idle. As the client population grew, inbound connections increased proportionally, making every new client cohort worsen the load on each host.

ZGateway collapses that mesh into two bounded hops: client to proxy and proxy to database host. By doing so, it moves connection pooling, request batching, retries, routing, caching and admission control into a single tier operated by the ZippyDB team. The proxy becomes the only place where the full workload can be observed, load attributed to its source and behavior changed in minutes. This eliminates the connection storms that previously caused file-descriptor exhaustion and host crashes.

The tradeoff of adding a proxy is an extra network hop and an additional tier to operate. Meta measures the computational overhead of ZGateway at roughly six percent for an average use case. The approach pays off when the client population is large, diverse and not directly controllable, which matches the situation of ZippyDB’s million-host client fleet.

ZGateway’s value assumes that underlying improvements such as ServiceRouter, Thrift overload protection and a thin client are already in place; without them the proxy tier would not be feasible. For workloads where the client fleet is small or can be updated quickly, the extra hop may not provide sufficient benefit to outweigh its cost. In such cases, direct access remains a viable alternative.