Fluxos
Protocolo inteiro, fim a fim
O gerador de carga executa payment flow e data flow completos, com PKCE, consent e polling. Não existe rota atalho no simulador. A única forma de receber 200 é navegar o protocolo certo.
Relatório de teste de carga · Abr 2026
52.000 req/s sustentados.
Erro de 0,001%.
É o número que o proxy regulado entrega em carga realista, calibrada com telemetria de produção. Na prática, o que está em pé hoje já roda em torno de 1,9× a média de horário comercial do Open Finance Brasil inteiro. O caminho para mais capacidade está mapeado.
Os quatro números
O que a infra entrega em carga realista.
As medições abaixo saíram do mesmo ambiente, com fluxos FAPI-BR completos e latência de produção. Não é throughput de papel, é o que está em pé hoje.
52k
req/s sustentados
Throughput estável em carga realista.
0,001%
taxa de erro realista
8 erros em 775.344 requisições no cenário calibrado por produção.
1.200×
maior iniciador do OF
Pico semanal do maior iniciador de pagamento do ecossistema.
500 s
para absorver esse pico
Tempo para processar os 26,06M requisições do pico semanal do maior iniciador.
Comparação
Quanta carga isso realmente é?
Baseado em análise interna de dados públicos do Dashboard do Cidadão. Inclui buffer pessimista de ~47% acima do pico semanal observado. A Cumbuca, como configurada, absorve quase duas vezes a média de horário comercial do ecossistema inteiro.
O que isso significa
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 reescala de arquitetura.
500segundos
O tempo para processar o pico semanal do maior iniciador de pagamento do Open Finance.
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 infra entrega hoje, esse volume inteiro passa em menos de nove minutos de operação.
O teto medido em 52k req/s é um teto 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. O caminho para mais capacidade já está definido: sharding de LBs, incremental, sem mudar uma linha da aplicação.
Como medimos
Fluxos FAPI-BR completos. Nada de tráfego sintético.
Cada virtual user executa o protocolo inteiro: payment consent, PAR, autorização, client credentials, auth code, iniciação PIX, polling. PKCE real, consent IDs reais, 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, não de um baseline sem latência.
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
O teto e o caminho além
Todo sistema tem um teto. O nosso é conhecido, e a saída também.
Onde para · 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
Onde vai · 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
Relatório completo
O relatório completo, com a metodologia e o teto.
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.
Envie o e-mail e a empresa. Um engenheiro do time entrega o PDF em até um dia útil.
No relatório
- Metodologia e topologia do teste§2, §3
- Resultados, status codes, latência§4
- Análise do gargalo mTLS e comparação com o ecossistema§5
- Roadmap de sharding§6
- Estimativa do ecossistema e sensibilidadeapêndice E
Registrado.
Um engenheiro do time recebe sua solicitação agora e responde com o PDF em até um dia útil. Se for urgente, escreva direto para bruno@cumbuca.com.
Próximo passo
Quer rodar o seu próprio benchmark?
Damos acesso a um ambiente de sandbox que espelha a produção. Você roda seu próprio k6 contra a infra real. Engenheiro no loop desde o primeiro e-mail.
Falar com engenharia