Benchmark Shows MongoDB Atlas Manages Thousands of Payments Per Second with Zero Data Loss

As instant payment rails replace legacy batch systems worldwide, banks need public proof that modern data architectures can scale without compromising resilience. We recently put the Icon Payments Framework (IPF), trusted by Tier 1 banks including Citi, NatWest, and BNP Paribas, through a series of extreme load and failure tests on MongoDB Atlas.

The results speak for themselves: 6,000 end-to-end payments per second, sub-second payment transaction latency, 430,000 database operations per second, and zero data loss during node failures. Below is a preview of the benchmark highlights, with full architectural breakdowns and testing methodologies available in our upcoming report.

Pushing the limits of scale and latency

To understand how the platform handles these extreme demands, we evaluated key performance metrics across a rigorous ladder test. At peak load, MongoDB Atlas comfortably supported 6,000 end-to-end payment transactions per second. This required the system to handle approximately 430,000 simultaneous database operations per second: roughly 236,000 operations on the IPF Event Journal and 196,000 operations on the Operational Data Store.

Figure 1. Deployment setup.

Despite this massive throughput, persistence latency remained below 30 milliseconds. This efficiency supported a mean end-to-end payment latency of just 0.51 seconds. Upgrading the database version played a significant role here; moving from MongoDB Atlas 8.0 to 8.3 reduced persistence latency by approximately 50%. For example, at 4,000 payment transactions per second, persistence latency dropped from 40 milliseconds to approximately 20 milliseconds. Across the entire test range of 500 to 6,000 transactions per second, throughput scaled predictably in near-linear lockstep, latency remained flat until the absolute peak, and hot-shard CPU utilization sat at only about half.

Engineered for extreme resilience

Sheer speed is irrelevant if the system breaks under failure. To validate high availability, we simulated real-world disaster conditions. During a MongoDB Atlas primary failover test, a new primary node was elected in an average of five seconds. Payment processing continued seamlessly without a single lost payment or the need for an application restart.

We also tested an unplanned application node failure.

Figure 2. Shard rebalancing mechanism to enable seamless recovery.

When a node went down, the system automatically and temporarily reduced throughput while redistributing traffic across the remaining nodes. The application returned to a stable 3,500 transactions per second in approximately 90 seconds. Most importantly, every single transaction reached a terminal state with absolutely zero data loss.