--- title: "Scale report" description: "The measurements in this report were taken in the same environment, with complete FAPI-BR flows and real latency. It is what runs in production today." url: "https://www.cumbuca.com/en/scale-report" lang: "en" --- # Scale report · April 2026 The measurements in this report were taken in the same environment, with complete FAPI-BR flows and real latency. It is what runs in production today. ## Realistic scenario · Apr 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 | ## We handle 1.9x more load than the entire Open Finance ecosystem. 52,000 req/s is what our regulated layer delivers under realistic load, calibrated with production telemetry. Without losing performance, and with 8 errors in 775,344 requests. The ceiling measured at 52,000 req/s belongs to the current configuration, not to the architecture. The layer that saturates under synthetic load is the mTLS termination at the load balancer, not the proxy application. | | | | | --- | --- | --- | | Cumbuca | Proxy as configured today | ~52,000 req/s | | Open Finance Brasil · Business hours | Effective average of the entire ecosystem | ~27,000 transactions/s | | Open Finance Brasil · 24×7 flattened | Total volume divided across the whole week | ~16,500 transactions/s | ## 1,200x the capacity of the largest payment initiator. The ecosystem's largest initiator generated 26.06 million requests in its peak week of the reference period. At the throughput our infrastructure delivers today, that entire volume goes through in under nine minutes of operation. The path to more capacity: LB sharding, incremental, without changing a line of the application. Time to process 26.06M requests (Peak of the largest Open Finance Brasil initiator): Cumbuca 500 seconds; Largest initiator in Open Finance Brasil 604,800 seconds. ## How it was measured: Complete FAPI-BR flows. Each virtual user ran the entire protocol: payment consent, PAR, authorization, client credentials, auth code, Pix initiation, polling. Real PKCE, real consent IDs and Bearer tokens with real scope. ### Flows: The whole protocol, end to end The load generator runs the complete payment and data flows, with PKCE, consent and polling. There is no shortcut route in the simulator. The only way to get a 200 is to navigate the protocol correctly. ### Latency: Calibrated with real telemetry The simulator answers with a piecewise-linear distribution anchored on the quantiles we measure in production: p50 at 130 ms, p90 at 350 ms, p99 at 1,350 ms. The reported result is under realistic load. ### Infra: Proxy pool of 120 instances 120 m8i.large instances behind an ALB with mTLS termination. 16 m8i.large run the Open Finance simulator. Two c5.9xlarge run k6 in parallel as the load generator. - 240 aggregate vCPUs on the proxy - Managed ALB • round-robin - k6 v1.7.1 • constant-arrival-rate ## Every system has a ceiling. Ours is known, and the way out is already mapped. The infrastructure as it stands would, in principle, absorb the normal load of the entire Open Finance ecosystem at once. Serving a single large customer leaves substantial headroom, even before any architectural re-scaling. ### Ceiling • 52,000 req/s: mTLS saturation at the load balancer Around 52k req/s, failures appear that scaling the proxy horizontally does not fix. The cause is the mTLS handshake cryptographic capacity at the load balancer. The bottleneck lives at the edge, not in the application. - 502 when the LB stops accepting new connections - 401 when the handshake times out - The proxy itself runs with headroom, no sign of saturation ### The way out • Linear sharding: Load balancer sharding The architectural path is pre-planned: multiple independent load balancers behind an L4 distributor. Each additional shard adds mTLS termination capacity linearly. 1. Linear scale: n shards, n× capacity 2. Zero changes to the proxy application 3. Incremental deploy, no service interruption 4. Transparent to the end customer ## Download the full report. English text, 38 pages, classified Confidential. Includes test topology, latency distribution, status codes, mTLS bottleneck analysis, comparison with the entire ecosystem, and the sharding roadmap. (Issued in April 2026) **Included in the report:** - Methodology and topology - Results, status codes and latency - mTLS bottleneck analysis and ecosystem comparison - Sharding roadmap - Ecosystem estimate and sensitivity [Download report](https://www.cumbuca.com/en/scale-report#baixar) --- ## About Cumbuca CUMBUCA Instituição de Pagamento Ltda., registered with the National Registry of Legal Entities of the Ministry of Finance (CNPJ/MF) under No. 44.353.942/0001-29, is authorized as a Payment Institution (IP), in the Payment Transaction Initiator (ITP) modality, regulated by the Central Bank of Brazil, pursuant to BCB Resolution No. 80 of March 25, 2021, and is a subsidiary of FAMÍLIA CUMBUCA HOLDING Ltda., registered with the CNPJ/MF under No. 32.670.659/0001-41. CUMBUCA Serviços de Tecnologia Ltda., registered with the CNPJ/MF under No. 50.271.185/0001-47, is also part of the same corporate group. - [This page in HTML](https://www.cumbuca.com/en/scale-report) - [Site index for LLMs (llms.txt)](https://www.cumbuca.com/llms.txt) - [Sitemap](https://www.cumbuca.com/sitemap.xml)