Monitoramento de Transações em Tempo Real: Arquiteturas que Processam 10 Mil TPS

Se você opera no mercado de pagamentos brasileiro em março de 2026, sabe que o Pix não perdoa latência. Bater 10 mil transações por segundo (TPS) deixou de ser um evento isolado de Black Friday. É uma terça-feira à tarde no Nubank, no Mercado Pago ou na infraestrutura da CIP.

O fraudador moderno não usa mais planilhas de Excel. Ele opera com scripts automatizados, botnets e inteligência artificial para testar milhares de credenciais vazadas por minuto. Se o seu motor de risco leva 200 milissegundos para analisar uma transação, o dinheiro já saiu da conta de origem, passou por duas contas laranja e virou criptoativo não rastreável.

O Banco Central apertou o cerco. As atualizações contínuas da Resolução Conjunta nº 6 e o aprimoramento do Mecanismo Especial de Devolução (MED) colocaram a responsabilidade financeira e regulatória no colo das instituições. Deixar a fraude passar custa caro. Bloquear transações legítimas por lentidão sistêmica custa a confiança do cliente e a receita de intercâmbio.

Observamos que a maioria das fintechs de médio porte ainda tenta adaptar arquiteturas legadas para resolver um problema de tempo real. Não funciona. Bancos de dados relacionais morrem na praia quando o volume passa de 2.000 TPS. Para escalar além dos 10.000 TPS com latência na casa dos 30 a 50 milissegundos, você precisa de uma mudança radical de paradigma.

O Fim do Batch: A Física do Tempo Real no Brasil

Até 2019, o mercado financeiro operava no conforto do D+1. O processamento em batch, rodando na madrugada, era suficiente para analisar o comportamento do cliente, cruzar dados com birôs de crédito e atualizar scores. O TED levava minutos ou horas. O cartão de crédito tinha a rede de proteção do chargeback e da análise manual posterior.

O Pix destruiu essa zona de conforto. Com liquidação em menos de 10 segundos ponta a ponta, o tempo que a instituição detentora da conta (o PSP) tem para aprovar ou negar a transação é minúsculo. A janela de oportunidade para o monitoramento de fraude caiu para cerca de 50 a 100 milissegundos.

Se você tentar fazer um 'SELECT COUNT(*)' em um banco PostgreSQL para saber quantas vezes um CPF transacionou nos últimos 15 minutos durante um pico de 10 mil TPS, seu banco de dados vai travar. O gargalo não é mais o poder de processamento da CPU, é o I/O (leitura e escrita) no disco. A latência de disco, mesmo em SSDs NVMe de altíssima performance, é incompatível com as exigências de um motor de decisão instantâneo.

O resultado? O mercado brasileiro foi forçado a adotar arquiteturas baseadas em eventos (Event-Driven Architectures) e processamento em memória.

A Anatomia de uma Arquitetura de 10.000 TPS

Construir um motor de risco capaz de suportar essa carga exige fatiar o problema em camadas ultra-especializadas. Nenhuma ferramenta faz tudo sozinha. A arquitetura padrão-ouro que vemos em players como Itaú, Stone e PagSeguro segue uma espinha dorsal muito clara.

Ingestão e Mensageria: O Tubo de Fogo com Apache Kafka

A primeira regra do processamento em altíssima escala é desacoplar quem gera a transação de quem analisa a transação. Quando o cliente aperta 'Pagar' no app, a requisição baté em um API Gateway e é imediatamente jogada em um tópico do Apache Kafka.

O Kafka funciona como um amortecedor gigante. Se o seu motor de risco sofrer um solavanco e atrasar 1 segundo, o Kafka segura a onda e impede que a API do cliente caia por timeout (o famoso backpressure). Com clusters bem dimensionados e partições distribuídas, o Kafka absorve fácilmente picos de 100.000 eventos por segundo. Ele garante que nenhum dado seja perdido, mesmo que os microsserviços de análise estejam operando no limite.

Processamento de Stream e Feature Stores: A Mágica do Flink

O dado está no Kafka. E agora? Você precisa calcular variáveis complexas em tempo real. O modelo de machine learning precisa saber: 'Qual é a velocidade média de gasto deste usuário nas últimas 24 horas?' ou 'Quantos CPFs distintos enviaram dinheiro para esta conta nos últimos 5 minutos?'.

Aqui entra o Apache Flink. Ao contrário de scripts tradicionais, o Flink processa o fluxo de dados do Kafka em movimento (stream processing). Ele mantém o estado dessas agregações na própria memória RAM (usando RocksDB para persistência local). O Flink calcula essas métricas contínuas (features) e as injeta em um Feature Store.

O Feature Store é a memória de curtíssimo prazo do seu motor de fraude. Ferramentas como Redis Enterprise ou Aerospike dominam esse nicho. Elas operam inteiramente em memória RAM, entregando tempos de leitura inferiores a 1 milissegundo. Quando o modelo de IA precisa das variáveis do cliente, ele não consulta um banco de dados lento; ele puxa tudo do Redis instantaneamente.

Bancos de Dados em Grafo para Redes de Fraude

O fraudador raramente age sozinho. Eles operam redes complexas de contas laranja, conectadas por transferências fracionadas. Modelos tradicionais olham apenas para o indivíduo. A fronteira atual da segurança envolve analisar os relacionamentos.

Bancos de dados em grafo, como Neo4j ou Amazon Neptune, mapeiam conexões. Em milissegundos, o motor de risco consulta o grafo: 'O dispositivo deste usuário já foi usado por alguma conta que sofreu bloqueio do MED nos últimos 30 dias?'. O grafo consegue encontrar caminhos e conexões ocultas (até 3 ou 4 graus de separação) que um banco relacional demoraria minutos para cruzar com dezenas de tabelas JOIN.

Machine Learning na Borda (Edge Scoring)

A última milha é a inferência do modelo de inteligência artificial. Carregar um modelo pesado em Python (como um XGBoost complexo ou uma rede neural profunda) e expor via API REST tradicional adiciona uma latência de rede intolerável (geralmente 20 a 40ms só de ida e volta).

Para resolver isso, gigantes brasileiros empacotam seus modelos em formatos otimizados (como ONNX) e rodam a inferência diretamente na mesma infraestrutura do motor de decisão, frequentemente usando linguagens de baixíssima latência e sem pausas imprevisíveis de Garbage Collection, como Rust, C++ ou Go. A inferência, que antes levava 50ms, cai para 2 ou 3 milissegundos.

Latência vs. Falsos Positivos: A Matemática do Risco

Na nossa análise, a maior dor de cabeça dos diretores de risco (CROs) não é a tecnologia em si, mas a calibração do negócio. Existe uma correlação direta entre o tempo que você tem para pensar e a precisão da sua decisão.

Se você tem apenas 20ms para aprovar uma transação, seu modelo será mais simples e conservador. Isso gera falsos positivos. Bloquear 1% de transações legítimas em um volume de 10.000 TPS significa bloquear 100 clientes bons por segundo. São 6.000 clientes irritados por minuto, inundando o call center e reclamando no Reclame Aqui. O custo operacional desse erro é devastador.

Por outro lado, se você relaxar as regras para evitar atrito, a fraude explode. Um ataque de credencial stuffing que passe despercebido por 30 segundos em um ambiente de alta velocidade pode drenar centenas de milhares de reais antes que qualquer alarme soe.

A arquitetura de ponta permite que você tenha o melhor dos dois mundos: a velocidade do tempo real com a profundidade analítica de um modelo complexo, graças à pré-computação de variáveis no Flink e à leitura ultra-rápida no Redis.

Como os Gigantes Brasileiros Operam na Prática

Não estamos falando de teorias de livros. O mercado brasileiro é um dos mais avançados do mundo em pagamentos instantâneos, superando os volumes do UPI indiano em proporcionalidade populacional.

O Nubank, por exemplo, construiu uma cultura de engenharia fortemente baseada em Clojure e arquiteturas imutáveis. Para o motor de risco, eles útilizam uma combinação agressiva de processamento de streams e machine learning proprietário que avalia desde a biometria comportamental (como o usuário digita no app) até o histórico transacional, tudo em frações de segundo.

A Stone, focada em adquirência, precisa autorizar transações de maquininhas no balcão da padaria. A paciência do consumidor na fila é zero. Eles útilizam Elixir e a máquina virtual do Erlang (BEAM), tecnologias criadas originalmente para o setor de telecomúnicações, projetadas exatamente para gerenciar milhões de conexões simultâneas com latência previsível, sem travar.

Players mais tradicionais, como o Itaú, passaram os últimos anos migrando cargas críticas do mainframe para a AWS, reconstruindo seus motores de autorização usando Kafka gerenciado (MSK) e bancos de dados NoSQL altamente escaláveis (como DynamoDB) para suportar os picos de demanda do Pix e das carteiras digitais.

Implicações Práticas: O Que Isso Significa Para Sua Operação

Se você opera um e-commerce, uma subadquirente ou uma fintech de nicho, preste atenção aqui: tentar construir essa infraestrutura do zero é suicídio financeiro e técnico. Manter um cluster de Kafka e Flink em alta disponibilidade exige uma equipe de engenharia de dados sênior que custa milhões por ano.

A recomendação técnica é buscar plataformas de prevenção à fraude no modelo SaaS que já possuam essa arquitetura sob o capô. Empresas como ClearSale, Feedzai e Konduto (agora Boa Vista) investiram pesado para expor APIs que respondem em milissegundos.

Se você é um Banco como Serviço (BaaS) fornecendo infraestrutura para terceiros, a responsabilidade é sua. Você precisará implementar padrões de Circuit Breaker. Se o motor de risco de terceiros falhar ou ficar lento, seu sistema deve ter um fallback configurado (aprovar com base em regras estáticas simples ou negar transações de alto valor) para evitar que a fila do Kafka acumule e derrube toda a sua operação de pagamentos.

O Futuro: Drex, Pix Automático e o Limite da Física

Olhando para o cenário que se consolida em 2026, o desafio de latência vai piorar antes de melhorar. O Pix Automático introduziu um volume massivo de transações recorrentes que ocorrem simultaneamente nas primeiras horas da manhã. O agendamento em massa testa os limites de concorrência dos bancos de dados.

O próximo grande teste da infraestrutura nacional é o Drex (o Real Digital). Com a introdução de contratos inteligentes (smart contracts) rodando em uma rede DLT (Distributed Ledger Technology), a etapa de liquidação exigirá validações criptográficas adicionais. Monitorar fraudes em um ambiente programável significa analisar não apenas o fluxo do dinheiro, mas a lógica do contrato inteligente que está sendo executado.

A física tem limites. A latência da rede de fibra ótica entre São Paulo (onde estão a maioria dos data centers da AWS/GCP/Azure) e os servidores do Banco Central em Brasília adiciona um tempo base que não pode ser superado. O diferencial competitivo das instituições financeiras não será mais quem tem o melhor algoritmo, mas quem tem a arquitetura de engenharia mais limpa, capaz de empurrar a decisão de machine learning o mais perto possível do clique do cliente.