DocDB architecture demonstrates how to achieve 5 million QPS and 5.5 nines without downtime. The key is zero-downtime data movement and strict platform-level control.
The problem does not manifest immediately — until the point when the load growth exceeds the limits of vertical scaling. The Stripe database started with a small number of MongoDB shards, to which applications connected directly. As the system grew, it reached dozens of shards, where maintenance operations were performed manually through ad hoc scripts. This created a bottleneck: any changes — from indexes to resharding — became risky and poorly scalable. As the load increased to millions of queries per second (QPS) and petabytes of data, this model began to threaten reliability.
The next limit is the physical constraints of vertical scaling. Individual shards grew to tens of terabytes. This temporarily solved the throughput problem but increased the blast radius during failures and complicated operations. With requirements at the level of 5.5 nines, even brief degradation becomes critical. In payment systems, this directly impacts the business: a transaction failure can lead to customer loss. The system faced not only scaling issues but also manageability challenges.
The solution evolved: a transition to horizontal scaling through a proprietary data platform. At its core is the DocDB architecture, built on top of MongoDB, but with strict access and behavior controls. A key element is the database proxy, which became the single entry point. It addresses several tasks: connection pooling, routing, admission control, and policy enforcement. This removes direct coupling between applications and shards and allows for centralized management.
Along with the proxy, two critical components emerged. The first is the routing metadata service, which dynamically maps logical partitions to physical shards. This eliminates static routing and enables transparent data movement. The second is the control plane, which automates the lifecycle of shards: creation, deletion, indexing, and maintenance. This shift transitions the system from a “pet care” mode to a “managed herd” model, where operations are standardized and automated.
The key technology is zero-downtime data movement. It allows for horizontal sharding, migrations, and updates without stopping the system. This is critical at 5 million QPS, where even a brief downtime is unacceptable. Architecturally, this is supported through a CDC pipeline: data from the MongoDB oplog is sent to Kafka and then to S3. This enables synchronization of state between old and new shard configurations and maintains consistency.
Implementation is not limited to adding components — the main challenge lies in consistency. When moving data, the system must maintain strong consistency, which is particularly important for financial operations. This limits the choice of migration strategies and requires precise control over the order of operations. Additionally, multi-tenancy with quotas imposes requirements for isolation: one client should not affect others, even under peak loads.
An additional layer is the limitation of MongoDB capabilities. Instead of a full API, the platform provides a minimal set of vetted operations. This reduces the risk of inefficient queries that could degrade latency or cause cascading failures. This approach is a compromise: less flexibility for developers, but greater predictability for the system.
The result is a platform capable of handling over 5 million queries per second on petabytes of data with a claimed reliability of 5.5 nines. It also achieves the ability to perform large-scale changes — sharding, migrations, updates — without downtime. Specific metrics on latency or operational costs are not disclosed, but architectural decisions indicate a priority on stability and manageability over maximum flexibility.
The DocDB architecture demonstrates a typical pattern for high-load systems: the abandonment of direct database access in favor of a platform layer, where control and automation are more important than raw performance. This is not a one-size-fits-all solution, but for systems with a high cost of errors and strict consistency requirements — it is a pragmatic choice.