Icon Solutions et MongoDB : IPF traite 6 000 paiements par seconde sans perte de données

Icon Solutions et MongoDB ont publié aujourd’hui les résultats d’un test de performance conjoint montrant que l’Icon Payments Framework (IPF), exécuté sur MongoDB Atlas, a traité 6 000 transactions de paiement de bout en bout par seconde (environ 430 000 opérations de base de données par seconde) avec une latence moyenne de bout en bout de 0,51 seconde, et s’est rétabli après des pannes de nœuds applicatifs comme de nœuds de base de données sans aucune perte de données.

Les volumes de paiements de compte à compte basculent rapidement vers les infrastructures instantanées. Le trafic migre des systèmes à règlement net vers les systèmes instantanés, et une partie des volumes de prélèvements devrait se reporter sur la demande de paiement (request-to-pay), avec un règlement via les systèmes instantanés. Pour les banques, cela signifie des pics de trafic plus marqués, une part croissante de paiements soumis aux SLA des systèmes de quelques secondes et aucune tolérance aux interruptions de service. Soutenir plusieurs milliers de paiements par seconde tout en préservant la résilience, la disponibilité et une faible latence est régulièrement sous-estimé par les établissements qui développent leurs propres solutions, et adapter des plateformes historiques à un traitement en continu constitue un défi de taille.

IPF est un framework de développement de paiements éprouvé à l’international, auquel font confiance des banques de premier rang (Tier 1) telles que Citi, NatWest et BNP Paribas. Reposant sur une architecture cloud native et pilotée par les événements, il a été conçu dès l’origine pour des environnements où l’échelle, la résilience et la disponibilité continue sont des exigences de base. Le test de performance a été conçu précisément pour le vérifier.

Le test s’est appuyé sur un flux de référence de paiements sortants SEPA Instant (virements instantanés en euros) dans lequel chaque paiement franchit 12 étapes de traitement distinctes – dont la détection des doublons, la validation des messages et des règles du système, le filtrage fraude et sanctions, la récupération des cours de change, la réservation et la comptabilisation des fonds, ainsi que la génération des messages du système –, les systèmes environnants de la banque étant représentés par des simulateurs. IPF et MongoDB Atlas ont été soumis à un test « par paliers » allant de 500 à 6 000 transactions de paiement cibles par seconde, afin d’observer le débit, la latence et la charge de la base de données à chaque étape plutôt qu’au seul pic. Des scénarios de panne ont ensuite été exécutés sous une charge transactionnelle réelle.

Principaux enseignements

• 6 000 paiements par seconde, de bout en bout. IPF a traité 6 000 transactions de paiement par seconde, chacune franchissant l’ensemble des 12 étapes de traitement. Ce débit métier reposait sur environ 430 000 opérations de base de données par seconde réparties sur deux clusters MongoDB Atlas : environ 236 000 sur l’IPF Event Journal et 196 000 sur l’IPF Operational Data Store.
• Une latence largement conforme aux SLA des paiements instantanés. La latence moyenne de bout en bout à 6 000 transactions par seconde s’est établie à 0,51 seconde, une fraction de la fenêtre de 10 secondes généralement accordée par les systèmes de paiement instantané. La latence de persistance est restée inférieure à 30 millisecondes, même au pic.
• Une montée en charge quasi linéaire et prévisible. De 500 à 6 000 transactions par seconde, l’application et la base de données ont évolué de concert : l’utilisation CPU et les taux d’insertion par shard ont progressé proportionnellement à chaque palier, et la latence est restée pratiquement stable jusqu’au haut de la plage. La capacité peut donc être prévue en toute confiance et la croissance planifiée en fonction de l’infrastructure, plutôt que comme un saut dans l’inconnu.
• Une marge confortable. À la charge maximale, l’utilisation CPU du shard le plus sollicité sur MongoDB Atlas se situait autour de 50 %, les pods du service de paiement IPF tournaient à environ 60 %, la file d’écriture de WiredTiger est restée à zéro et le retard de réplication est demeuré faible tout au long du test.
• Un rétablissement après panne sans perte de données. Sous une charge réelle de 3 500 transactions par seconde, IPF s’est rétabli d’une panne brutale d’un nœud applicatif en moins de 90 secondes et d’un arrêt planifié d’un nœud en environ 60 secondes. Dans les deux cas, chaque transaction a atteint un état final sans perte de données ni intervention manuelle : le rééquilibrage des shards d’IPF redistribue les transactions en cours vers les nœuds restants et reconstitue leur état à partir des événements persistés.
• Un basculement de la base de données mesuré en secondes. Par ailleurs, un basculement du nœud primaire de MongoDB Atlas – réalisé à l’aide du test de basculement intégré d’Atlas, que les clients peuvent lancer eux-mêmes – s’est achevé en 5 secondes environ en moyenne, le traitement des paiements se poursuivant sans interruption, sans perte de paiement ni redémarrage de l’application.
• Les gains de la plateforme se traduisent directement en performances de paiement. Le passage de MongoDB Atlas 8.0 à 8.3 a réduit la latence de persistance d’environ 50 %, d’environ 40 millisecondes à environ 20 millisecondes à 4 000 transactions par seconde.

Pour les banques et les prestataires de services de paiement, la portée est concrète : une capacité qui se planifie au lieu de se deviner, des pannes qui se résolvent sans intervention manuelle et une voie vers une infrastructure de paiement moderne qui n’impose ni de tout développer en interne ni d’adapter une plateforme historique. C’est l’architecture qui a rendu ces résultats possibles.

Ces résultats ont été obtenus grâce à une architecture distribuée à montée en charge horizontale, et non avec du matériel surdimensionné. IPF s’exécutait sous la forme de 12 pods applicatifs sur Kubernetes répartis sur trois zones de disponibilité d’une même région cloud, en s’appuyant sur Akka pour un traitement concurrent et tolérant aux pannes, sur les flux à contre-pression de l’IPF Connector Framework pour éviter que les systèmes en aval de lutte contre la fraude, de filtrage des sanctions et de comptabilité ne soient submergés à mesure que la charge augmentait, et sur Kafka pour acheminer les données de traitement vers l’Operational Data Store. La persistance suit les modèles d’event sourcing et de CQRS, MongoDB Atlas servant de socle à la fois à l’IPF Event Journal (un cluster de cinq shards) et à l’IPF Operational Data Store (un cluster de six shards). Chaque shard tournait sur un niveau de classe M80 doté de 32 vCPU et de 128 Go de RAM.

La capacité peut être accrue en poussant plus loin le sharding et en séparant les services : en distinguant les paiements de masse des paiements unitaires, en répartissant les flux entre initiation, exécution et compensation des paiements, ou en les séparant géographiquement. Le test de performance ouvre donc une voie claire au-delà de 6 000 transactions par seconde pour les banques et les prestataires de services de paiement qui en ont besoin. Chaque service séparé est capable à lui seul de traiter plusieurs milliers de transactions par seconde.

« Les banques ont besoin d’une infrastructure de paiement capable de s’adapter à une économie instantanée », a déclaré Toine van Beusekom, directeur de la stratégie d’Icon Solutions. « Pourtant, soutenir des milliers de paiements par seconde tout en préservant la résilience, la disponibilité, l’évolutivité et une latence ultra-faible n’est pas simple, en particulier pour les établissements qui reposent sur une architecture historique ou qui développent tout eux-mêmes. Ce test de performance démontre qu’IPF offre une approche alternative, conçue pour répondre aux exigences sans précédent d’un monde toujours connecté, et qui permet aux banques de faire progresser les paiements en toute confiance. »

« À 6 000 paiements par seconde, la couche de données gère près d’un demi-million d’opérations de base de données par seconde, avec un rétablissement en cinq secondes après une panne de nœud et zéro perte de données », a déclaré Boris Bialek, vice-président Industries et Global Field CTO de MongoDB. « Les paiements instantanés exigent un socle de données dynamique et piloté par les événements, et pas simplement un système d’enregistrement statique, et ce test de performance montre ce que MongoDB offre en temps réel, avec une marge confortable. Échelle, résilience et performance opérationnelle sur une seule plateforme managée. C’est le moteur des paiements modernes. »

Accéder au rapport du test de performance : Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments.

L’ensemble complet des données, y compris l’échelle complète des indicateurs pour chaque palier de 500 à 6 000 transactions de paiement par seconde et des précisions supplémentaires sur la manière dont les résultats ont été obtenus, est disponible sur demande auprès d’Icon Solutions ou de MongoDB.