See how IPF and MongoDB perform under the demands of an always-on world
Payment volumes are growing, processing windows are shrinking and resilience is non-negotiable. Banks need payments infrastructures that can handle significantly higher throughput without compromising performance, availability or data integrity.
Icon Solutions and MongoDB put that challenge to the test.
This new benchmark report demonstrates how the Icon Payments Framework (IPF), running on MongoDB Atlas, performed as payment volumes were progressively increased from 500 to 6,000 transactions per second – testing throughput, latency, scalability and resilience under real failure conditions.
The results at a glance:
-
6,000
end-to-end payment transactions per second
-
~430,000
database operations per second at peak
-
0.51 seconds
mean end-to-end latency at 6,000 TPS
-
<90 seconds
recovery from application node failure, with zero data loss
-
~5 seconds
average recovery from MongoDB Atlas database node failure
The benchmark also demonstrated close-to-linear scalability, with meaningful capacity still in reserve at peak load.
What you'll learn
Download the report to explore:
-
How IPF and MongoDB were put to the test, including the architecture and representative SEPA Instant payment flow used in the benchmark.
-
What happens as volumes increase, with testing progressing from 500 to 6,000 target payment TPS.
-
How low latency was maintained at scale, including persistence latency of under 30 milliseconds at peak.
-
How the platform responds when things go wrong, with planned and unplanned application node failures tested under active transaction load.
-
Why the architecture can scale beyond 6,000 TPS, using service segregation and horizontal database sharding rather than relying on ever-larger individual machines.
Built for the realities of always-on payments
Throughput alone isn't enough. Modern payment infrastructure needs to keep processing when components fail.
During the benchmark, IPF and MongoDB were subjected to failure scenarios while processing 3,500 payments per second. In an unplanned application node failure, transactions were queued and subsequently processed, the system recovered to full normal processing in around 90 seconds, and no data was lost.
The result is a practical demonstration of how modern, event-driven payments architecture can combine scale, low latency and resilience rather than forcing banks to trade one for another.
Get the report
See the architecture, methodology and results behind the benchmark – and what they mean for banks and PSPs planning for the next generation of instant payments.