Fluxos
Protocolo inteiro, fim a fim
O gerador de carga executa o fluxo de pagamentos e de dados completos, com PKCE, consentimento e polling. Não existe rota atalho no simulador. A única forma de receber 200 é navegar o protocolo certo.
Relatório de escala
Abril 2026As medições deste relatório foram realizadas no mesmo ambiente, com fluxos FAPI-BR completos e latência real. É o que está rodando em produção hoje.
Cenário realista · Abr 2026
SnapshotThroughput
51.927
req/s
Total requests
778.905
Error rate
0,007
%
P50
217
ms
P99
1.578
ms
VUS (peak)
53.753
Aguentamos 1.9x mais carga do que o ecossistema Open Finance inteiro.
52.000 reqs/s é o que a nossa camada regulada entrega em carga realista, calibrada com telemetria de produção. Sem perder performance e com uma taxa de 8 erros em 775.344 requisições.
O teto medido em 52.000 reqs/s é da configuração atual, não da arquitetura. A camada que satura sob carga sintética é a terminação mTLS no load balancer, não a aplicação do proxy.
Capacidade 1200x acima do maior iniciador de pagamento.
O maior iniciador do ecossistema gerou 26,06 milhões de requisições na sua semana de pico do período de referência. No throughput que a nossa infraestrutura entrega hoje, esse volume inteiro passa em menos de nove minutos de operação.
O caminho para mais capacidade: sharding de LBs, incremental, sem mudar uma linha da aplicação.
Como foi feita a medição
Fluxos FAPI-BR completos.
Cada usuário virtual executou o protocolo inteiro: payment consent, PAR, autorização, client credentials, auth code, iniciação PIX, polling. PKCE real, consent IDs reais, e Bearer tokens com escopo real.
Latência
Calibrada com telemetria real
O simulador responde com uma distribuição linear por partes, ancorada nos quantis que a gente mede em produção: p50 em 130 ms, p90 em 350 ms, p99 em 1.350 ms. O resultado reportado é de carga realista.
Infra
Pool de proxy de 120 instâncias
120 instâncias m8i.large atrás de um ALB com terminação mTLS. 16 m8i.large rodam o simulador Open Finance. Dois c5.9xlarge rodam o k6 em paralelo como gerador de carga.
- 240 vCPU agregados no proxy
- ALB gerenciado • round-robin
- k6 v1.7.1 • constant-arrival-rate
Todo sistema tem um teto. O nosso é conhecido e a saída já está mapeada.
A infraestrutura como está, em princípio, absorveria a carga normal do ecossistema Open Finance inteiro simultaneamente. Atender um cliente grande sozinho deixa folga substancial, antes mesmo de qualquer re-escala de arquitetura.
Teto • 52.000 req/s
Saturação de mTLS no load balancer
Em torno de 52k req/s, aparecem falhas que escalar proxy horizontalmente não resolve. A causa é a capacidade criptográfica de handshake mTLS no load balancer. O gargalo mora no edge, não na aplicação.
- 502 quando o LB não aceita novas conexões
- 401 quando o handshake estoura timeout
- Proxy em si opera com folga, sem sinal de saturação
A saída • Sharding linear
Sharding do load balancer
O caminho arquitetural é pré-planejado: múltiplos load balancers independentes atrás de um distribuidor L4. Cada shard adicional adiciona capacidade de terminação mTLS de forma linear.
- Escala linear: n shards, n× capacidade
- Zero mudança na aplicação do proxy
- Deploy incremental, sem interrupção de serviço
- Transparente para o cliente final
Baixe o relatório completo.
Texto em inglês, 38 páginas, classificação Confidential. Inclui topologia do teste, distribuição de latência, status codes, análise do gargalo mTLS, comparação com o ecossistema inteiro, e roadmap de sharding.
Emitido em abril 2026Incluído no relatório
- Metodologia e topologia
- Resultados, status codes e latência
- Análise do gargalo mTLS e comparação com o ecossistema
- Roadmap de sharding
- Estimativa do ecossistema e sensibilidade