Icon Solutions und MongoDB: IPF schafft 6.000 Zahlungen pro Sekunde ohne Datenverlust

Icon Solutions und MongoDB haben heute die Ergebnisse eines gemeinsamen Benchmarks veröffentlicht. Demnach verarbeitete das Icon Payments Framework (IPF) auf MongoDB Atlas 6.000 durchgängige Zahlungstransaktionen pro Sekunde (rund 430.000 Datenbankoperationen pro Sekunde) bei einer mittleren End-to-End-Latenz von 0,51 Sekunden und erholte sich sowohl von Ausfällen von Anwendungs- als auch von Datenbankknoten ohne jeglichen Datenverlust.

Konto-zu-Konto-Zahlungsvolumina verlagern sich rasch auf Instant-Payment-Infrastrukturen. Der Verkehr wandert von Netto-Settlement-Verfahren zu Instant-Verfahren, und bei Lastschriftvolumina wird erwartet, dass sie teilweise zu Request-to-Pay mit Abwicklung über Instant-Verfahren übergehen. Für Banken bedeutet das ausgeprägtere Lastspitzen, einen wachsenden Anteil von Zahlungen, die an Scheme-SLAs von wenigen Sekunden gebunden sind, und null Toleranz für Ausfallzeiten. Mehrere Tausend Zahlungen pro Sekunde dauerhaft zu verarbeiten und dabei Resilienz, Verfügbarkeit und niedrige Latenz zu gewährleisten, wird von Instituten, die selbst entwickeln, regelmäßig unterschätzt, und die Nachrüstung von Altplattformen für eine Verarbeitung rund um die Uhr ist eine erhebliche Herausforderung.

IPF ist ein international bewährtes Framework für die Entwicklung von Zahlungslösungen, auf das Tier-1-Banken wie Citi, NatWest und BNP Paribas setzen. Es basiert auf einer cloudnativen, ereignisgesteuerten Architektur und wurde von Anfang an für Umgebungen konzipiert, in denen Skalierbarkeit, Resilienz und ständige Verfügbarkeit Grundvoraussetzungen sind. Genau das sollte der Benchmark testen.

Der Benchmark nutzte einen Referenzablauf für ausgehende SEPA-Instant-Zahlungen (Echtzeitüberweisungen in Euro), bei dem jede Zahlung 12 einzelne Verarbeitungsschritte durchläuft – darunter Dublettenprüfung, Validierung von Nachrichten und Scheme-Regeln, Betrugs- und Sanktionsprüfung, Abruf von Devisenkursen, Reservierung und Verbuchung von Mitteln sowie Erstellung der Scheme-Nachrichten –, wobei die umliegenden Systeme der Bank durch Simulatoren abgebildet wurden. IPF und MongoDB Atlas durchliefen einen „Leiter“-Test von 500 bis 6.000 angestrebten Zahlungstransaktionen pro Sekunde, sodass Durchsatz, Latenz und Datenbanklast auf jeder Stufe und nicht nur unter Spitzenlast beobachtet werden konnten. Anschließend wurden Ausfallszenarien unter laufender Transaktionslast durchgespielt.

Die wichtigsten Ergebnisse

• 6.000 Zahlungen pro Sekunde, durchgängig. IPF verarbeitete 6.000 Zahlungstransaktionen pro Sekunde, von denen jede alle 12 Verarbeitungsschritte durchlief. Gestützt wurde dieser geschäftliche Durchsatz von rund 430.000 Datenbankoperationen pro Sekunde auf zwei MongoDB-Atlas-Clustern: etwa 236.000 auf dem IPF Event Journal und 196.000 auf dem IPF Operational Data Store.
• Latenz deutlich innerhalb der SLAs für Echtzeitzahlungen. Die mittlere End-to-End-Latenz bei 6.000 Transaktionen pro Sekunde lag bei 0,51 Sekunden – ein Bruchteil des 10-Sekunden-Fensters, das Instant-Payment-Verfahren üblicherweise vorsehen. Die Persistenzlatenz blieb selbst unter Spitzenlast unter 30 Millisekunden.
• Nahezu lineare, vorhersehbare Skalierung. Von 500 bis 6.000 Transaktionen pro Sekunde skalierten Anwendung und Datenbank im Gleichschritt: CPU-Auslastung und Einfügeraten pro Shard stiegen mit jeder Stufe der Leiter proportional an, und die Latenz blieb bis zum oberen Ende des Bereichs im Wesentlichen konstant. Die Kapazität lässt sich daher zuverlässig prognostizieren und Wachstum als Funktion der Infrastruktur planen statt als Sprung ins Ungewisse.
• Reichlich Reserven. Unter Spitzenlast lag die CPU-Auslastung des Hot Shards auf MongoDB Atlas bei rund 50 %, die IPF-Zahlungsdienst-Pods liefen bei rund 60 %, die WiredTiger-Schreibwarteschlange blieb bei null und die Replikationsverzögerung war durchgehend gering.
• Wiederherstellung nach Ausfällen ohne Datenverlust. Unter einer laufenden Last von 3.500 Transaktionen pro Sekunde erholte sich IPF von einem unkontrollierten Ausfall eines Anwendungsknotens in weniger als 90 Sekunden und von einer geplanten Knotenabschaltung in rund 60 Sekunden. In beiden Fällen erreichte jede Transaktion einen Endzustand – ohne Datenverlust und ohne manuelles Eingreifen: Das Shard-Rebalancing von IPF verteilt laufende Transaktionen auf die verbleibenden Knoten und stellt ihren Zustand aus persistierten Ereignissen wieder her.
• Datenbank-Failover in Sekunden. Separat dazu wurde ein Failover des Primärknotens von MongoDB Atlas – durchgeführt mit dem integrierten Failover-Test von Atlas, den Kunden selbst ausführen können – im Durchschnitt in etwa 5 Sekunden abgeschlossen; die Zahlungsverarbeitung lief dabei durchgehend weiter, ohne Zahlungsverluste oder Neustarts der Anwendung.
• Plattformverbesserungen schlagen direkt auf die Zahlungsleistung durch. Der Wechsel von MongoDB Atlas 8.0 auf 8.3 senkte die Persistenzlatenz um etwa 50 % – von rund 40 Millisekunden auf rund 20 Millisekunden bei 4.000 Transaktionen pro Sekunde.

Für Banken und Zahlungsdienstleister ist die Bedeutung ganz praktisch: Kapazität, die sich planen lässt, statt geschätzt werden zu müssen, Ausfälle, die sich ohne manuelles Eingreifen beheben, und ein Weg zu einer modernen Zahlungsinfrastruktur, der weder eine komplette Eigenentwicklung noch die Nachrüstung einer Altplattform erfordert. Möglich wurden diese Ergebnisse durch die Architektur.

Erzielt wurden die Ergebnisse mit einer verteilten, horizontal skalierenden Architektur statt mit überdimensionierter Hardware. IPF lief als 12 Anwendungs-Pods auf Kubernetes über drei Verfügbarkeitszonen in einer einzigen Cloud-Region. Dabei kamen Akka für nebenläufige, fehlertolerante Verarbeitung zum Einsatz, die Streams mit Backpressure des IPF Connector Framework, damit nachgelagerte Betrugs-, Sanktions- und Buchhaltungssysteme bei steigender Last nicht überlastet werden, sowie Kafka, um Verarbeitungsdaten in den Operational Data Store zu streamen. Die Persistenz folgt den Mustern Event Sourcing und CQRS, wobei MongoDB Atlas sowohl das IPF Event Journal (ein Cluster mit fünf Shards) als auch den IPF Operational Data Store (ein Cluster mit sechs Shards) trägt. Jeder Shard lief auf einer Instanz der Klasse M80 mit 32 vCPUs und 128 GB RAM.

Zusätzliche Kapazität lässt sich durch weiteres Sharding und durch die Aufteilung von Diensten gewinnen: etwa durch die Trennung von Sammel- und Einzelzahlungen, die Aufteilung der Abläufe auf Zahlungsauslösung, -ausführung und Clearing oder eine geografische Trennung. Der Benchmark zeigt damit einen klaren Weg über 6.000 Transaktionen pro Sekunde hinaus für Banken und Zahlungsdienstleister, die das benötigen. Jeder abgetrennte Dienst ist für sich genommen in der Lage, mehrere Tausend Transaktionen pro Sekunde zu verarbeiten.

„Banken brauchen eine Zahlungsinfrastruktur, die sich an eine Echtzeitwirtschaft anpassen kann“, sagte Toine van Beusekom, Strategy Director bei Icon Solutions. „Doch Tausende Zahlungen pro Sekunde dauerhaft zu verarbeiten und dabei Resilienz, Verfügbarkeit, Skalierbarkeit und extrem niedrige Latenz zu gewährleisten, ist nicht einfach, insbesondere für Institute, die auf Altarchitekturen setzen oder alles selbst entwickeln. Dieser Benchmark zeigt, dass IPF einen alternativen Ansatz bietet, der darauf ausgelegt ist, die beispiellosen Anforderungen einer Always-on-Welt zu erfüllen, und Banken in die Lage versetzt, den Zahlungsverkehr mit Zuversicht voranzubringen.“

„Bei 6.000 Zahlungen pro Sekunde bewältigt die Datenschicht fast eine halbe Million Datenbankoperationen pro Sekunde, mit einer Wiederherstellung nach Knotenausfällen in fünf Sekunden und ohne Datenverlust“, sagte Boris Bialek, Vice President of Industries und Global Field CTO bei MongoDB. „Echtzeitzahlungen erfordern ein dynamisches, ereignisgesteuertes Datenfundament und nicht bloß ein statisches System of Record, und dieser Benchmark zeigt, was MongoDB in Echtzeit leistet – mit reichlich Reserven. Skalierbarkeit, Resilienz und operative Leistung auf einer einzigen verwalteten Plattform. Das ist der Motor des modernen Zahlungsverkehrs.“

Zum Benchmark-Bericht: Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments.

Der vollständige Datensatz, einschließlich der kompletten Messwertleiter für jede Stufe von 500 bis 6.000 Zahlungstransaktionen pro Sekunde sowie weiterer Details dazu, wie die Ergebnisse erzielt wurden, ist auf Anfrage bei Icon Solutions oder MongoDB erhältlich.