NewPower reliable AI agents with accurate, relevant data Read the blog >  >>
NewBuild software faster with AI agents—without losing control Read the blog > >>

Scale without sacrifice

Enterprise AI is stuck in pilot. Learn what fragmentation costs and how a unified intelligence layer helps you move agents into production.

Download Report

The shift to instant account-to-account payments

The account-to-account (A2A) payments ecosystem is rapidly evolving. Banks now operate in a 24x7 world where consumers expect immediate settlement for both domestic and international transfers. As traffic shifts from net settlement schemes to instant schemes—and direct debits move toward request-to-pay models—instant payment volumes are surging.

To handle these demand spikes and strict multi-second SLAs, financial institutions require ultra-resilient payment systems and databases built for extreme throughput.

To address this challenge, Icon Solutions and MongoDB benchmarked the scalability, latency, and resilience needed for modern, high-volume payment processing environments.

The proof: half a million operations/sec

The benchmark report on the Icon Payments Framework (IPF) on MongoDB Atlas reveals extreme throughput, ultra-low latency, and resilience under peak payment loads.
Download Report

6,000 payments/sec

Sustained 6,000 end-to-end payments per second, executing 12 steps per transaction—including validations and core banking calls.

Sub-second processing

Held persistence under 30ms with a 0.51s average end-to-end response time at 6,000 TPS—well within standard 10s SLAs.

Linear scaling

Achieved near-linear scalability from baseline to peak load, maintaining significant system headroom in reserve.

Zero data loss

Recovered from node failure in an average of five seconds during resilience testing—with zero data loss and minimal latency impact.

430k ops/second

Handled 430k database ops/sec at peak across MongoDB stores: 236k on the IPF event journal and 196k on the IPF ODS.

<90s node recovery

Recovered from application node failures in under 90 seconds, maintaining zero data loss and minimal latency impact.

Inside the benchmark test

See how IPF and MongoDB Atlas manage orchestration, event journal inserts, and real-time streaming under peak payment loads.
REFERENCE ARCHITECTURE

End-to-end SEPA instant flow

Our benchmark models a complete outbound Single Euro Payments Area (SEPA) instant payment solution. Every transaction spans the full processing lifecycle, executing 12 functional steps across core payment logic and external system integrations.

  • Executes 12 discrete events per transaction
  • Includes native IPF logic like duplicate checks
  • Integrates external simulators (e.g., accounting)
Diagram for Scale Without Sacrifice Benchmark
Diagram #2 for Scale Without Sacrifice Benchmark
DEPLOYMENT COVERAGE

High-throughput sharded architecture

The test deployment scaled from 500 to 6,000 target payment transactions per second (TPS) across 12 application pods, Kafka services, and sharded MongoDB Atlas clusters sized specifically for write-intensive operational workloads.

  • 12 IPF application pods with integrated Kafka services
  • 5-shard cluster for Event Journal; 6-shard cluster for ODS
  • M80-class tier shards (32 vCPUs, 128 GB RAM)

Engineered for the extreme

Meet non-functional requirements with a modern, always-on architecture built to handle high throughput, low latency, and resilience.

Meeting the toughest non-functional requirements

Sustaining thousands of payments—and hundreds of thousands of database operations—per second while maintaining low latency and ultra-resilience is no small feat. Banks often underestimate this challenge when self-building, while legacy vendors struggle to retro-architect outdated systems for always-on processing.

The Icon Payments Framework (IPF) and MongoDB are built from the ground up on modern architectural patterns. Non-functional requirements (NFRs) were never an afterthought—they were baked into the platform from day one.

Technology

Akka framework

Concurrent processing

Underpins IPF’s fault-tolerant execution model, scaling the same code seamlessly across a 12-pod cluster.

Technology

IPF connectors

Back-pressured streams

Built on Alpakka to protect downstream systems (fraud, sanctions, accounting) from overload during peak traffic spikes.

Technology

Apache Kafka

Real-time streaming

Continuously streams payment processing data from active flows directly into the Operational Data Store.

Technology

Kubernetes

Elastic infrastructure

Orchestrates multi-region deployments to provide an elastic, self-healing infrastructure layer under heavy loads.

Pattern

Event sourcing

Complete auditability

Stores full sequence event logs to allow exact current-state derivation through reliable event replay.

Pattern

CQRS pattern

Decoupled operations

Command query responsibility segregation (CQRS) enables non-blocking writes and independent read-model scaling.

Why MongoDB is central to the benchmark

MongoDB provides the resilient foundation needed for event-driven processing, keeping pace with high-throughput app scaling.

Enabling event-driven scale without bottlenecks

MongoDB is more than background infrastructure—it is the core enabler of this benchmark’s success. A platform built for instant processing must do more than persist transactions; it must continuously absorb high-ingest activity while delivering fast access to richly indexed operational data.

By backing both the IPF event journal and the IPF operational data store (ODS), MongoDB concurrently supported two distinct high-throughput workload profiles, ensuring the data layer kept pace with the application rather than becoming a bottleneck.

Workload 1

IPF event journal

High-volume ingest

Handled high-volume event persistence, reaching ~236,000 database operations per second at peak load.

Workload 2

Operational data store

Rich operational queries

Supported complex BI queries and indexing, reaching ~196,000 database operations per second at peak.

Combined peak

430k total ops/sec

Scale without bottlenecks

Processed ~430k total database ops/sec across both clusters while maintaining low-latency SLAs.

Platform performance gains

Upgrading to MongoDB Atlas 8.3 cut persistence latency in half, providing smooth ingest and significant headroom for growth.

50% latency drop

Moving to Atlas 8.3 slashed persistence latency from 40ms to ~20ms at 4,000 TPS, showing immediate gains for high-volume workloads.

50% peak CPU

Hot-shard CPU utilization stayed at ~50% at peak load, keeping the WiredTiger write queue at zero with low replication lag throughout.

Modernization

Proves financial institutions can unify scale, resilience, and operational querying in one platform—with room to scale well beyond 6k TPS.

Beyond 6,000 Payment TPS

Explore the roadmap to even greater scale through service segregation and horizontal database sharding.

The roadmap to even greater scale

For institutions requiring higher volumes, this benchmark highlights a clear path forward. Achieving 6,000 TPS was not done through brute force on oversized infrastructure but through a distributed architecture designed to scale out horizontally. This gives banks a practical, flexible growth model that avoids relying on ever-larger, costly single machines.

Service segregation

Boost throughput by separating bulk from individual payments, segregating by geography, or splitting by payment value chain.

Horizontal sharding

Increase throughput by adding database shards, distributing peak workloads without pushing hardware to its technical limits.

Future-proof growth

Maximize infrastructure utilization and room for growth while maintaining ultra-low latency and production resilience.

Diagrams 3 for Scale Without Sacrifice Benchmark

Resilience under real failure

Testing application stability under active peak pressure with both planned and unplanned node failure scenarios.

Built to bend, not break: resilience under real failure conditions

Throughput is only half the story; resilience under stress is the other. To evaluate real-world fault tolerance, we tested failure scenarios under an active load of 3,500 TPS—measuring system response, latency, and data integrity in real time.

Scenario 1: graceful node shutdown (planned)

Simulates a planned rolling deployment taking 1 of 12 nodes offline:

  • Throughput: Maintained 3,500 TPS with zero throughput drop.
  • Latency: Impact isolated to the departing node; P50 and P95 latencies remained flat.
  • Recovery: Full normal processing restored in ~60 seconds upon node re-entry.
  • Data integrity: Zero data loss; all transactions reached a terminal state.

Scenario 2: ungraceful kill/node failure (unplanned)

Simulates an unexpected node failure under active peak load:

  • Throughput: Temporary drop to ~1,000 TPS during recovery; queued traffic was processed evenly once restored.
  • Latency: Cluster-wide impact with a temporary 45-second increase at P99.
  • Recovery: Full normal processing restored in ~90 seconds.
  • Data integrity: Zero data loss; all transactions reached a terminal state.

The mechanisms for ensuring seamless recovery

Both failure scenarios demonstrated complete recovery within seconds, zero data loss, and minimal customer impact. This seamless fault tolerance is achieved through a three-step automated process:

  • Immediate detection: When a node fails, the system detects the disruption instantly and stops routing new transactions to that node.
  • Shard rebalancing: Active transactions on the failed node are automatically redistributed across the remaining cluster nodes.
  • Event-driven rehydration: Rebalanced transactions restore their processing state directly from persisted events in MongoDB, allowing them to resume execution seamlessly.
Diagram 4 for Scale Without Sacrifice Benchmark
Recovery impact

90-second catch-up

Cluster throughput briefly dips during node failover, returning to full 3,500 TPS capacity within 90 seconds.

SLA mitigation

Automated rerouting

Payments exceeding 10s SLAs during a failover can automatically reroute to non-instant rails or re-execute based on rule configs.

Operations

Zero manual touch

IPF automatically handles ledger compensations and booking reversals, eliminating stuck states and manual intervention.

MongoDB Atlas failover test

Validating built-in primary failover with 5-second recovery, zero data loss, and uninterrupted payment continuity under load.

~5s primary failover

Validated via Atlas UI/API—electing a new primary in ~5 seconds with zero payment loss or application restarts.

Operational headroom

Ample database capacity made failover invisible; under heavier load, it resulted only in minor, temporary tail-latency waves.

Always-on continuity

Driver and application retry logic ensured seamless payment processing through unplanned database disruptions.

Scale Without Sacrifice

Request access to the full benchmark report to explore detailed test metrics and architectural insights from 500 to 6,000 TPS.
Contact UsDownload report
BENCHMARK HIGHLIGHTS
  • Sustained 6,000 TPS across 12 end-to-end steps
  • Sub-second latency (0.51s mean E2E at 6k TPS)
  • 430,000 peak database operations per second
  • 50% persistence latency reduction on Atlas 8.3
  • 5-second database failover with zero data loss