Icon Solutions e MongoDB: IPF processa 6 mil pagamentos por segundo sem perda de dados

A Icon Solutions e a MongoDB publicaram hoje os resultados de um benchmark conjunto que mostra que o Icon Payments Framework (IPF), executado no MongoDB Atlas, processou 6.000 transações de pagamento de ponta a ponta por segundo (cerca de 430.000 operações de banco de dados por segundo) com latência média de ponta a ponta de 0,51 segundo, e se recuperou de falhas tanto em nós de aplicação quanto de banco de dados sem nenhuma perda de dados.

Os volumes de pagamentos de conta para conta estão migrando rapidamente para infraestruturas instantâneas. O tráfego está passando dos esquemas de liquidação líquida para os esquemas instantâneos, e a expectativa é que parte dos volumes de débito direto migre para a solicitação de pagamento (request-to-pay), com liquidação por meio de esquemas instantâneos. Para os bancos, isso significa picos de tráfego mais acentuados, uma parcela crescente de pagamentos sujeitos a SLAs dos esquemas de poucos segundos e nenhuma tolerância a indisponibilidade. Sustentar vários milhares de pagamentos por segundo mantendo resiliência, disponibilidade e baixa latência é algo rotineiramente subestimado pelas instituições que desenvolvem suas próprias soluções, e adaptar plataformas legadas para processamento ininterrupto é um desafio significativo.

O IPF é um framework de desenvolvimento de pagamentos comprovado internacionalmente, no qual confiam bancos de primeira linha (Tier 1) como Citi, NatWest e BNP Paribas. Construído sobre uma arquitetura nativa em nuvem e orientada a eventos, ele foi projetado desde o início para ambientes em que escala, resiliência e disponibilidade contínua são requisitos básicos. O benchmark foi elaborado justamente para testar isso.

O benchmark utilizou um fluxo de referência de pagamentos de saída SEPA Instant (transferências instantâneas em euros) no qual cada pagamento completa 12 etapas de processamento individuais – incluindo verificação de duplicidade, validação de mensagens e de regras do esquema, triagem de fraude e sanções, obtenção de câmbio, reserva e lançamento de fundos e geração de mensagens do esquema –, com os sistemas do entorno do banco representados por simuladores. O IPF e o MongoDB Atlas passaram por um teste “em escada” de 500 a 6.000 transações de pagamento por segundo como meta, para que throughput, latência e carga do banco de dados pudessem ser observados em cada etapa, e não apenas no pico. Em seguida, cenários de falha foram executados sob carga real de transações.

Principais conclusões

• 6.000 pagamentos por segundo, de ponta a ponta. O IPF processou 6.000 transações de pagamento por segundo, cada uma completando todas as 12 etapas de processamento. Esse throughput de negócio foi sustentado por cerca de 430.000 operações de banco de dados por segundo em dois clusters do MongoDB Atlas: aproximadamente 236.000 no IPF Event Journal e 196.000 no IPF Operational Data Store.
• Latência bem dentro dos SLAs de pagamentos instantâneos. A latência média de ponta a ponta com 6.000 transações por segundo foi de 0,51 segundo, uma fração da janela de 10 segundos que os esquemas de pagamentos instantâneos normalmente permitem. A latência de persistência ficou abaixo de 30 milissegundos mesmo no pico.
• Escalabilidade quase linear e previsível. De 500 a 6.000 transações por segundo, aplicação e banco de dados escalaram em sincronia: a CPU e as taxas de inserção por shard aumentaram proporcionalmente a cada degrau da escada, e a latência permaneceu praticamente estável até o topo da faixa. Assim, a capacidade pode ser prevista com confiança e o crescimento planejado em função da infraestrutura, em vez de ser um salto no escuro.
• Folga de sobra. Na carga máxima, a utilização de CPU do shard mais carregado no MongoDB Atlas ficou em torno de 50%, os pods do serviço de pagamentos do IPF operaram em cerca de 60%, a fila de escrita do WiredTiger permaneceu em zero e o atraso de replicação se manteve baixo durante todo o teste.
• Recuperação de falhas sem perda de dados. Sob uma carga real de 3.500 transações por segundo, o IPF se recuperou de uma falha abrupta de um nó de aplicação em menos de 90 segundos e de um desligamento planejado de nó em cerca de 60 segundos. Em ambos os casos, todas as transações chegaram a um estado final sem perda de dados e sem intervenção manual: o rebalanceamento de shards do IPF redistribui as transações em andamento para os nós restantes e reconstitui seu estado a partir dos eventos persistidos.
• Failover do banco de dados medido em segundos. Separadamente, um failover do nó primário do MongoDB Atlas – executado com o teste de failover nativo do Atlas, que os próprios clientes podem rodar – foi concluído em cerca de 5 segundos, em média, com o processamento de pagamentos continuando normalmente e sem perda de pagamentos ou reinicializações da aplicação.
• Ganhos da plataforma se traduzem diretamente em desempenho de pagamentos. A migração do MongoDB Atlas 8.0 para o 8.3 reduziu a latência de persistência em cerca de 50% – de aproximadamente 40 milissegundos para aproximadamente 20 milissegundos com 4.000 transações por segundo.

Para bancos e prestadores de serviços de pagamento, a relevância é prática: capacidade que pode ser planejada em vez de estimada no chute, falhas que se resolvem sem intervenção manual e um caminho para uma infraestrutura de pagamentos moderna que não exige desenvolver tudo internamente nem adaptar uma plataforma legada. O que tornou esses resultados possíveis foi a arquitetura.

Os resultados foram alcançados por meio de uma arquitetura distribuída e de escalabilidade horizontal, e não com hardware superdimensionado. O IPF foi executado como 12 pods de aplicação no Kubernetes, distribuídos em três zonas de disponibilidade de uma única região de nuvem, usando Akka para processamento concorrente e tolerante a falhas, os streams com contrapressão do IPF Connector Framework para evitar que os sistemas downstream de fraude, sanções e contabilidade ficassem sobrecarregados à medida que a carga aumentava, e Kafka para transmitir os dados de processamento ao Operational Data Store. A persistência segue os padrões de event sourcing e CQRS, com o MongoDB Atlas dando suporte tanto ao IPF Event Journal (um cluster de cinco shards) quanto ao IPF Operational Data Store (um cluster de seis shards). Cada shard rodou em um tier da classe M80 com 32 vCPUs e 128 GB de RAM.

É possível adicionar capacidade ampliando o sharding e segregando serviços: separando pagamentos em lote dos individuais, dividindo os fluxos entre iniciação, execução e compensação de pagamentos, ou fazendo a separação por região geográfica. Assim, o benchmark aponta um caminho claro para ir além de 6.000 transações por segundo para os bancos e prestadores de serviços de pagamento que precisarem. Cada serviço segregado é capaz, por si só, de processar vários milhares de transações por segundo.

“Os bancos precisam de uma infraestrutura de pagamentos capaz de se adaptar a uma economia instantânea”, disse Toine van Beusekom, diretor de Estratégia da Icon Solutions. “No entanto, sustentar milhares de pagamentos por segundo mantendo resiliência, disponibilidade, escalabilidade e latência ultrabaixa não é fácil, principalmente para instituições que dependem de arquitetura legada ou que desenvolvem tudo por conta própria. Este benchmark demonstra que o IPF oferece uma abordagem alternativa, projetada para atender às demandas sem precedentes de um mundo sempre conectado, permitindo que os bancos conduzam a evolução dos pagamentos com confiança.”

“Com 6.000 pagamentos por segundo, a camada de dados processa quase meio milhão de operações de banco de dados por segundo, com recuperação de falhas de nó em cinco segundos e zero perda de dados”, disse Boris Bialek, vice-presidente de Indústrias e CTO global de campo da MongoDB. “Pagamentos instantâneos exigem uma base de dados dinâmica e orientada a eventos, e não simplesmente um sistema de registro estático, e este benchmark mostra o que a MongoDB entrega em tempo real, com folga de sobra. Escala, resiliência e desempenho operacional em uma única plataforma gerenciada. Esse é o motor dos pagamentos modernos.”

Acesse o relatório do benchmark: Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments.

O conjunto de dados completo, incluindo a escada completa de métricas para cada etapa de 500 a 6.000 transações de pagamento por segundo e mais detalhes sobre como os resultados foram obtidos, está disponível mediante solicitação à Icon Solutions ou à MongoDB.