--- title: "Relatório de escala" description: "As 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." url: "https://www.cumbuca.com/relatorio-de-escala" lang: "pt-BR" --- # Relatório de escala · Abril 2026 As 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 | | | | --- | --- | | Throughput | 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. | | | | | --- | --- | --- | | Cumbuca | Proxy como configurado hoje | ~52.000 req/s | | Open Finance Brasil · Horário comercial | Média efetiva do ecossistema inteiro | ~27.000 transações/s | | Open Finance Brasil · 24×7 achatado | Volume total dividido pela semana inteira | ~16.500 transações/s | ## 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. Tempo para processar 26,06M de requisições (Pico do maior iniciador do Open Finance Brasil): Cumbuca 500 segundos; Maior iniciador do Open Finance Brasil 604.800 segundos. ## 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. ### 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. ### 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. 1. Escala linear: n shards, n× capacidade 2. Zero mudança na aplicação do proxy 3. Deploy incremental, sem interrupção de serviço 4. 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 2026) **Incluí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 [Baixar relatório](https://www.cumbuca.com/relatorio-de-escala#baixar) --- ## Sobre a Cumbuca CUMBUCA Instituição de Pagamento Ltda., inscrita no Cadastro Nacional da Pessoa Jurídica do Ministério da Fazenda (CNPJ/MF) sob o nº 44.353.942/0001-29, é autorizada como Instituição de Pagamento (IP), na modalidade de Iniciador de Transações de Pagamento (ITP), regulada pelo Banco Central do Brasil, conforme a Resolução BCB nº 80, de 25 de março de 2021, e é subsidiária da FAMÍLIA CUMBUCA HOLDING Ltda., inscrita no CNPJ/MF sob o nº 32.670.659/0001-41. Também faz parte do mesmo grupo societário a CUMBUCA Serviços de Tecnologia Ltda., inscrita no CNPJ/MF sob o nº 50.271.185/0001-47. - [Esta página em HTML](https://www.cumbuca.com/relatorio-de-escala) - [Índice do site para LLMs (llms.txt)](https://www.cumbuca.com/llms.txt) - [Sitemap](https://www.cumbuca.com/sitemap.xml)