Icon Solutions y MongoDB: IPF procesa 6.000 pagos por segundo sin perder datos ante fallos

Icon Solutions y MongoDB publicaron hoy los resultados de una prueba de rendimiento conjunta que muestra que el Icon Payments Framework (IPF), ejecutado sobre MongoDB Atlas, procesó 6.000 transacciones de pago de extremo a extremo por segundo (alrededor de 430.000 operaciones de base de datos por segundo) con una latencia media de extremo a extremo de 0,51 segundos, y se recuperó de fallos tanto en nodos de aplicación como de base de datos sin pérdida de datos.

Los volúmenes de pagos de cuenta a cuenta se están trasladando rápidamente a infraestructuras instantáneas. El tráfico migra de los esquemas de liquidación neta a los esquemas instantáneos, y se prevé que parte de los volúmenes de domiciliaciones bancarias pase a la solicitud de pago (request-to-pay) con liquidación a través de esquemas instantáneos. Para los bancos, esto significa picos de tráfico más pronunciados, una proporción creciente de pagos sujetos a SLA de los esquemas de pocos segundos y ninguna tolerancia a la inactividad. Las entidades que desarrollan sus propias soluciones suelen subestimar lo que supone sostener varios miles de pagos por segundo manteniendo la resiliencia, la disponibilidad y una baja latencia, y adaptar plataformas heredadas para un procesamiento ininterrumpido es un reto considerable.

IPF es un marco de desarrollo de pagos de eficacia probada a escala internacional, en el que confían bancos de primer nivel (Tier 1) como Citi, NatWest y BNP Paribas. Construido sobre una arquitectura nativa de la nube y orientada a eventos, fue diseñado desde el principio para entornos en los que la escala, la resiliencia y la disponibilidad continua son requisitos básicos. La prueba de rendimiento se diseñó precisamente para comprobarlo.

La prueba utilizó un flujo de referencia de pagos salientes SEPA Instant (transferencias inmediatas en euros) en el que cada pago completa 12 pasos de procesamiento individuales –entre ellos la detección de duplicados, la validación de mensajes y de reglas del esquema, el control de fraude y sanciones, la obtención del tipo de cambio, la reserva y el asiento de fondos y la generación de mensajes del esquema–, con los sistemas circundantes del banco representados mediante simuladores. IPF y MongoDB Atlas se sometieron a una prueba «escalonada» de 500 a 6.000 transacciones de pago objetivo por segundo, de modo que el rendimiento, la latencia y la carga de la base de datos pudieran observarse en cada fase y no solo en el pico. A continuación, se ejecutaron escenarios de fallo con carga de transacciones real.

Principales conclusiones

• 6.000 pagos por segundo, de extremo a extremo. IPF procesó 6.000 transacciones de pago por segundo, cada una de las cuales completó los 12 pasos de procesamiento. Ese rendimiento de negocio se sustentó en alrededor de 430.000 operaciones de base de datos por segundo en dos clústeres de MongoDB Atlas: aproximadamente 236.000 en el IPF Event Journal y 196.000 en el IPF Operational Data Store.
• Latencia muy por debajo de los SLA de los pagos instantáneos. La latencia media de extremo a extremo con 6.000 transacciones por segundo fue de 0,51 segundos, una fracción de la ventana de 10 segundos que suelen permitir los esquemas de pagos instantáneos. La latencia de persistencia se mantuvo por debajo de 30 milisegundos incluso en el pico.
• Escalado casi lineal y predecible. De 500 a 6.000 transacciones por segundo, la aplicación y la base de datos escalaron de forma acompasada: el uso de CPU y las tasas de inserción por fragmento aumentaron proporcionalmente con cada escalón, y la latencia se mantuvo prácticamente plana hasta el extremo superior del rango. Por tanto, la capacidad puede preverse con confianza y el crecimiento puede planificarse en función de la infraestructura, en lugar de ser un salto a lo desconocido.
• Margen de sobra. Con la carga máxima, la utilización de CPU del fragmento más activo en MongoDB Atlas rondó el 50%, los pods del servicio de pagos de IPF funcionaron en torno al 60%, la cola de escritura de WiredTiger se mantuvo en cero y el retraso de replicación siguió siendo bajo en todo momento.
• Recuperación ante fallos sin pérdida de datos. Con una carga real de 3.500 transacciones por segundo, IPF se recuperó de un fallo abrupto de un nodo de aplicación en menos de 90 segundos y de un apagado planificado de un nodo en unos 60 segundos. En ambos casos, todas las transacciones alcanzaron un estado final sin pérdida de datos y sin intervención manual: el reequilibrio de fragmentos de IPF redistribuye las transacciones en curso entre los nodos restantes y reconstruye su estado a partir de los eventos persistidos.
• Conmutación por error de la base de datos en segundos. Por otra parte, una conmutación por error del nodo primario de MongoDB Atlas –ejecutada con la prueba de conmutación integrada de Atlas, que los propios clientes pueden realizar– se completó en unos 5 segundos de media, sin que el procesamiento de pagos se interrumpiera y sin pérdida de pagos ni reinicios de la aplicación.
• Las mejoras de la plataforma se traducen directamente en rendimiento de pagos. El paso de MongoDB Atlas 8.0 a 8.3 redujo la latencia de persistencia en torno a un 50%, de unos 40 milisegundos a unos 20 milisegundos con 4.000 transacciones por segundo.

Para los bancos y los proveedores de servicios de pago, la importancia es práctica: una capacidad que puede planificarse en lugar de estimarse a ciegas, fallos que se resuelven sin intervención manual y una vía hacia una infraestructura de pagos moderna que no exige desarrollarlo todo internamente ni adaptar una plataforma heredada. Lo que hizo posibles esos resultados es la arquitectura.

Los resultados se lograron mediante una arquitectura distribuida de escalado horizontal, y no con hardware sobredimensionado. IPF se ejecutó como 12 pods de aplicación en Kubernetes repartidos en tres zonas de disponibilidad de una única región en la nube, utilizando Akka para un procesamiento concurrente y tolerante a fallos, los flujos con contrapresión del IPF Connector Framework para evitar que los sistemas posteriores de fraude, sanciones y contabilidad se vieran desbordados a medida que aumentaba la carga, y Kafka para transmitir los datos de procesamiento al Operational Data Store. La persistencia sigue los patrones de event sourcing y CQRS, con MongoDB Atlas como soporte tanto del IPF Event Journal (un clúster de cinco fragmentos) como del IPF Operational Data Store (un clúster de seis fragmentos). Cada fragmento se ejecutó en un nivel de clase M80 con 32 vCPU y 128 GB de RAM.

Se puede añadir capacidad fragmentando aún más y segregando servicios: separando los pagos masivos de los individuales, dividiendo los flujos entre iniciación, ejecución y compensación de pagos, o separándolos geográficamente. Por tanto, la prueba de rendimiento apunta a una vía clara para superar las 6.000 transacciones por segundo para los bancos y proveedores de servicios de pago que lo necesiten. Cada servicio segregado es capaz por sí solo de procesar varios miles de transacciones por segundo.

«Los bancos necesitan una infraestructura de pagos capaz de adaptarse a una economía instantánea», afirmó Toine van Beusekom, director de Estrategia de Icon Solutions. «Sin embargo, sostener miles de pagos por segundo manteniendo la resiliencia, la disponibilidad, la escalabilidad y una latencia ultrabaja no es fácil, sobre todo para las entidades que dependen de arquitecturas heredadas o que lo desarrollan todo por su cuenta. Esta prueba de rendimiento demuestra que IPF ofrece un enfoque alternativo, diseñado para responder a las exigencias sin precedentes de un mundo siempre activo, que permite a los bancos liderar con confianza la evolución de los pagos».

«Con 6.000 pagos por segundo, la capa de datos gestiona casi medio millón de operaciones de base de datos por segundo, con una recuperación ante fallos de nodo en cinco segundos y sin pérdida de datos», afirmó Boris Bialek, vicepresidente de Industrias y CTO global de campo de MongoDB. «Los pagos instantáneos requieren una base de datos dinámica y orientada a eventos, no simplemente un sistema de registro estático, y esta prueba de rendimiento muestra lo que MongoDB ofrece en tiempo real, con margen de sobra. Escala, resiliencia y rendimiento operativo en una única plataforma gestionada. Ese es el motor de los pagos modernos».

Acceda al informe de la prueba de rendimiento: Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments.

El conjunto de datos completo, que incluye la escala completa de métricas para cada escalón de 500 a 6.000 transacciones de pago por segundo y más detalles sobre cómo se obtuvieron los resultados, está disponible previa solicitud a Icon Solutions o MongoDB.