Cloud Native Desde o Dia Zero: Como a CERC Conecta Mais de 80% dos Participantes do Mercado de Cartões do Brasil
TL;DR — A CERC nunca operou on-premise. Desde a fundação, a infraestrutura que sustenta o registro de recebíveis do mercado financeiro brasileiro foi construída 100% na nuvem do Google Cloud. Hoje, o resultado é uma plataforma que processa 100 mil transações por segundo, armazena petabytes de dados, e atende mais de 80% das credenciadoras e subcredenciadoras do mercado de cartões do país. Este artigo conta como chegamos aqui — e por que o Cloud Spanner é a peça central dessa história.
O Que a CERC Faz (E Por Que Isso Importa)
A CERC é uma Infraestrutura do Mercado Financeiro (IMF) — uma das entidades que formam a base sobre a qual o sistema financeiro brasileiro opera. Nossa missão é dar transparência e segurança ao registro, análise e controle de liquidação de ativos financeiros usados como garantia em operações de crédito.
Na prática, isso significa o seguinte: quando um estabelecimento comercial usa seus recebíveis de cartão de crédito como garantia para obter um empréstimo, é a CERC que registra, valida e dá autenticidade a essa operação. Sem esse registro centralizado, a assimetria de informação entre credores e devedores tornaria o mercado de crédito mais caro, mais lento e mais arriscado.
A escala desse trabalho é significativa. A CERC processa recebíveis que sustentam bilhões de reais em comércio diário. E o mercado de recebíveis de cartão é apenas uma das classes de ativos que registramos. Duplicatas, recebíveis do agronegócio e outras categorias seguem o mesmo caminho.
Por Que Cloud Native Desde o Início
Quando a CERC foi fundada, uma decisão arquitetural definiu tudo o que viria depois: não haveria infraestrutura on-premise. Zero. Nenhum rack, nenhum data center próprio, nenhum hardware para escalar manualmente.
Essa não foi uma decisão trivial. Estávamos criando uma IMF — uma entidade regulada do sistema financeiro — e a expectativa do mercado era de ambientes tradicionais, controlados e fisicamente isolados. Mas a natureza do problema que resolvemos exigia uma abordagem diferente.
Antes da operação em produção, não havia informações precisas para estimar o volume de transações que o mercado demandaria. Podiam ser milhares. Podiam ser milhões. A incerteza era a única certeza. E em um cenário de incerteza de escala, a nuvem não é uma opção — é a única resposta racional.
Na prática, a escolha pelo Google Cloud foi natural: precisávamos de um parceiro com experiência comprovada em escala massiva, que oferecesse não apenas infraestrutura, mas um ecossistema de serviços gerenciados que nos permitisse focar no problema de negócio — e não em gerenciar servidores. A história da CERC se desenvolveu junto do Google Cloud, e essa co-evolução moldou a arquitetura que temos hoje.
A Arquitetura: Cada Peça No Seu Lugar
A infraestrutura da CERC é composta por serviços do Google Cloud que se complementam para atender requisitos simultâneos de escala, consistência, disponibilidade e segurança.
Cloud Spanner — O Coração Transacional
O Cloud Spanner é a peça mais crítica da nossa arquitetura. É o banco de dados onde as transações de registro de recebíveis acontecem — e onde consistência não é negociável.
O que torna o Spanner único no mercado é algo que, por muito tempo, foi considerado impossível em ciência da computação: combinar consistência forte (ACID) com escalabilidade horizontal ilimitada em um banco de dados distribuído globalmente.
Bancos de dados tradicionais te forçam a escolher: ou você tem consistência forte com escala limitada (bancos relacionais clássicos), ou tem escala ilimitada com consistência eventual (bancos NoSQL). O Spanner elimina esse trade-off.
Para a CERC, isso se traduz em capacidades concretas:
- Escala sob demanda: aumentamos e diminuímos o poder de processamento sem parar o ambiente. Em um mercado financeiro onde janelas de manutenção são inaceitáveis, isso é fundamental.
- 99,999% de disponibilidade: o famoso “cinco noves” — menos de 5 minutos de downtime por ano. Para uma IMF que processa transações que sustentam o crédito de milhões de empresas, indisponibilidade não é uma opção.
- Consistência ACID distribuída: toda transação é atômica, consistente, isolada e durável — mesmo quando os dados estão distribuídos entre múltiplos nós. Em um sistema financeiro, uma transação parcialmente aplicada é pior do que uma transação que falhou.
A CERC não começou com o Spanner. Inicialmente, utilizávamos o Cloud SQL — um banco de dados relacional gerenciado, perfeitamente adequado para os volumes iniciais. À medida que o mercado de recebíveis cresceu, a migração para o Cloud Spanner foi a decisão que nos permitiu escalar sem comprometer a integridade transacional.
Na minha experiência, o momento em que migramos para o Spanner foi um ponto de inflexão. A confiança de saber que o banco escala horizontalmente sem comprometer consistência transacional muda a forma como você projeta sistemas. Você para de pensar em workarounds para limitações de infraestrutura e passa a pensar no problema de negócio.
BigQuery — A Camada Analítica
Se o Spanner é o coração transacional, o BigQuery é o sistema nervoso analítico. É onde processamos terabytes de dados para gerar insights, relatórios regulatórios e compartilhar informações com os outros players do mercado.
O BigQuery permite que a CERC ofereça transparência ao ecossistema financeiro — um dos nossos valores fundamentais. Os dados de recebíveis processados e analisados no BigQuery alimentam desde modelos internos de risco até os relatórios que o Banco Central exige.
Google Kubernetes Engine (GKE) — A Camada de Aplicação
Toda a camada de aplicação da CERC roda em microsserviços orquestrados pelo GKE. Isso nos dá flexibilidade para escalar serviços individuais de forma independente, fazer deploys sem downtime e manter a agilidade de desenvolvimento mesmo com um sistema em produção que processa 100 mil transações por segundo.
O GKE é também onde servimos nossas APIs, permitindo que participantes do mercado se integrem à CERC de forma programática e escalável.
100 Mil Transações por Segundo
Esse é o número que define a escala da operação. 100.000 transações por segundo — cada uma delas registrando, validando ou consultando recebíveis que representam dinheiro real de empresas reais.
Para colocar em perspectiva: quando o projeto de recebíveis de cartão entrou em produção, não existia benchmark de mercado para o volume que seria processado. A regulação do Banco Central era clara nos requisitos, mas o volume real só seria conhecido quando o sistema estivesse operando.
A arquitetura cloud native da CERC — com Spanner escalando processamento sem parar, GKE orquestrando microsserviços, e BigQuery processando a camada analítica — é o que permite absorver esse volume com estabilidade. Não é um pico eventual. É a operação normal.
E o armazenamento acompanha: petabytes de dados mantidos, processados e disponíveis para consulta pelos participantes do mercado.
O Que Significa Ser uma IMF Inovadora
O mercado de Infraestruturas do Mercado Financeiro é, por natureza, conservador. As IMFs são entidades reguladas que formam a espinha dorsal do sistema financeiro — e a expectativa geral é de estabilidade acima de tudo.
A CERC desafia essa premissa. Ser cloud native desde o dia zero, em um segmento onde on-premise era o padrão, foi um ato de inovação. Mas inovação na CERC vai além da escolha de infraestrutura.
É sobre como construímos software. É sobre ter um time de engenharia que opera com autonomia, que usa as melhores ferramentas do mercado, que resolve problemas de escala que poucas empresas no Brasil enfrentam. É sobre um ambiente onde engenheiros trabalham com Cloud Spanner, BigQuery, Kubernetes, Apache Airflow, agentes de IA autônomos — e onde cada uma dessas tecnologias resolve um problema real, não um requisito de currículo.
No dia a dia, isso se traduz em resolver problemas que não têm solução pronta no mercado. Quando o Banco Central definiu as regras para registro de recebíveis de cartão, não existia um playbook de como processar esse volume com essa criticidade. A solução foi construída aqui dentro — e continua evoluindo.
Na minha visão, o próximo grande salto está na hipervalorização dos dados que já temos. Não basta registrar e armazenar — precisamos extrair inteligência, identificar padrões e gerar valor a partir da massa de informações que processamos diariamente. Criar essa cultura de dados no mercado financeiro brasileiro é um dos objetivos que me motivam, e a nuvem é a base que torna isso possível.
O Que Vem a Seguir
A classificação de recebíveis de cartão é apenas uma das classes de recebíveis — representando cerca de 15% do total de recebíveis da economia brasileira. Todas as demais categorias, incluindo duplicatas, recebíveis do agronegócio e outros, seguem o mesmo caminho de digitalização e registro centralizado.
A visão da CERC é transformar todos os recebíveis da economia em ativos plenamente utilizáveis pelos seus donos, para que isso resulte em mais acesso a crédito para financiar o crescimento dos negócios.
Nessa jornada, a exploração de Apigee para um modelo API-first em toda a organização, o uso de Machine Learning para novos serviços, e a expansão da capacidade analítica com BigQuery são investimentos concretos que estão sendo realizados.
A infraestrutura está pronta. A escala está provada. O próximo capítulo é expandir o impacto — e a nuvem será essencial nesse processo.
Tecnologias
| Camada | Tecnologia |
|---|---|
| Banco de dados transacional | Cloud Spanner |
| Processamento analítico | BigQuery |
| Orquestração de containers | Google Kubernetes Engine (GKE) |
| Gerenciamento de APIs | Apigee |
| Orquestração de dados | Apache Airflow (Cloud Composer) |
| Infraestrutura | Google Cloud (100% cloud native) |
A CERC é a infraestrutura do mercado financeiro que atende mais de 80% das credenciadoras e subcredenciadoras do mercado de cartões do Brasil — 100 mil transações por segundo, petabytes de dados, zero infraestrutura on-premise. Se você quer trabalhar em problemas de escala real, com tecnologia de ponta e impacto direto no sistema financeiro brasileiro — estamos contratando.
Este post foi escrito por: Vitor Melon | Head de Engenharia — Plataforma de Arranjos de Pagamentos.