Meta Introduces ZGateway: Stateless Proxy Tier for ZippyDB
Meta unveils ZGateway, a stateless proxy tier unifying ZippyDB traffic to handle over 1 billion operations per second while reducing connection overhead.
Stock photo for illustration only, not from the actual event
- Meta introduces ZGateway as a stateless proxy tier for ZippyDB
- Handles more than 1 billion operations per second
- Carries about 40% of ZippyDB traffic, projected over 60%
- Mitigates TLS connection exhaustion and prevents fleet reboot loops
Under direct access architecture, every ZippyDB client connected directly to every database host it required. A single client could touch tens of thousands of shards across hundreds of thousands of hosts, forcing both typical clients and database hosts to maintain tens of thousands of TLS connections. Each idle connection consumed memory, CPU, and file descriptors on both ends, while inbound connection counts scaled up with every new client cohort. Reconnection storms frequently caused system crashes driven by file descriptor exhaustion and out-of-memory (OOM) errors. In one notable incident, a routing bug forced every client to open a connection per shard, plunging the entire server fleet into a reboot loop. Client-side fixes proved impractical because hundreds of separate teams own the client fleet.
To address these scaling bottlenecks, Meta developed ZGateway, functioning as a stateless proxy tier positioned between ZippyDB clients and the ZServer database fleet. According to Meta, the system handles over 1 billion operations per second and currently carries approximately 40% of all ZippyDB traffic, with projections to exceed 60%, all while incurring only about 6% computational overhead for typical use cases.
Stock photo for illustration only, not from the actual event
ZGateway runs as regional tiers discovered via ServiceRouter, Meta’s service mesh, deployed in two distinct flavors: a pure proxy and a read-through cache. The underlying engine utilizes Meta’s thick C++ ZippyDB client, making ZGateway effectively operate as a managed service running a ZippyDB client.
Deploying a stateless proxy tier in large-scale database infrastructures effectively abstracts connection management complexity. Instead of allowing millions of clients to hammer hundreds of thousands of database hosts directly—which exposes hardware resources to exhaustion risks—introducing an intermediary layer for connection pooling and request batching dramatically stabilizes distributed database fleets operating at Meta's massive scale.
Clients transmit requests over a sticky connection to a regional ZGateway host. The proxy then terminates TLS, authorizes against the use case's ACLs, applies per-tenant admission control and traffic shaping, resolves shard locations, checks local caches on caching tiers, batches the request alongside concurrent work destined for that shard, and forwards it to the appropriate replicas. Responses are demultiplexed and returned alongside per-use-case metrics, traces, and quota usage records. Throughout this workflow, TLS handling remains within the Thrift/ServiceRouter stack while replica selection stays inside the embedded client.
Source: MarkTechPost
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment