Menu
InfoQ Architecture·September 28, 2026

Meta's ZGateway: Scaling ZippyDB Connections with a Stateless Proxy

Meta introduced ZGateway, a stateless proxy layer for its distributed key-value store, ZippyDB, to address extreme connection and reliability challenges from over a million client hosts. By centralizing connection management and traffic control, ZGateway significantly reduces persistent connections by 19x while handling over a billion operations per second, improving database efficiency and resilience. This architectural shift offloads critical tasks like authentication, authorization, caching, and request batching from the database servers.

Read original on InfoQ Architecture

Meta's ZGateway is an architectural solution designed to overcome the scaling challenges associated with direct client connections to a massively distributed database like ZippyDB. ZippyDB, Meta's key-value store, supports critical workloads across its global infrastructure. The original direct access model, where each client connects to many database shards, led to a dense many-to-many connection mesh, causing issues like file descriptor exhaustion and out-of-memory conditions due to connection storms, especially with over a million client hosts.

ZGateway Architecture and Benefits

ZGateway introduces a managed, stateless proxy tier between clients and ZippyDB servers. This layer acts as a connection consolidator, significantly reducing the number of persistent connections to the database hosts. Clients maintain sticky connections to regional gateway hosts, which then manage a controlled fleet of connections to the ZippyDB servers. This architecture has been instrumental in reducing total persistent connections by approximately 19x and per-host connection counts by 97-98%.

ℹ️

Key Architectural Trade-offs

Introducing an additional network hop via ZGateway might seem counter-intuitive for latency-sensitive systems. However, Meta found that this trade-off actually *improves* overall latency by offloading the significant overhead of connection management from the database nodes, allowing them to focus purely on data operations. This highlights a common system design principle: judiciously adding layers can improve overall system performance and stability by specializing concerns.

Core Responsibilities of ZGateway

  • Connection Pooling & Multiplexing: Consolidates connections from numerous clients into a smaller, managed set for database servers.
  • Authentication & Authorization: Centralizes security checks for incoming requests.
  • Admission Control: Applies per-tenant traffic management to prevent overload.
  • Shard Resolution: Directs requests to the correct ZippyDB shards.
  • Local Caching: Improves read performance by serving frequently accessed data closer to the client.
  • Request Batching & Coalescing: Optimizes database interactions by combining multiple client requests into fewer, larger requests, reducing overhead.
  • Load Balancing & Overload Protection: Distributes traffic efficiently and sheds load gracefully during high stress, ensuring system stability. In tests, it allowed 99.9% of requests to proceed under 90% CPU load while shedding traffic for a small percentage of tenants.

ZGateway leverages Meta's existing C++ ZippyDB client and integrates with ServiceRouter for service discovery. It supports both pure proxy and read-through caching modes, offering flexibility in deployment and optimization. The ability to progressively route traffic (by service, shard prefix, percentage, or region) and a global kill switch provides robust control and rollback capabilities during deployment or incidents.

Comparison to Similar Patterns

The proxy pattern used by ZGateway is prevalent in various distributed systems, including connection poolers, service meshes, CDNs, and API gateways. While their specific responsibilities and scaling trade-offs differ, the core idea of an intermediary layer managing and optimizing client-server interactions remains consistent. ZGateway specifically adds a shared traffic management layer in front of ZippyDB's existing sharding, replication, and failure detection capabilities.

proxyconnection poolingstateless servicedistributed databasekey-value storescalabilitytraffic managementmeta

Comments

Loading comments...