Cloud Native From Day Zero: How CERC Connects Over 80% of Brazil's Card Market Participants
TL;DR — CERC has never operated on-premise. Since its founding, the infrastructure that supports receivables registration for the Brazilian financial market has been built 100% on Google Cloud. Today, the result is a platform that processes 100,000 transactions per second, stores petabytes of data, and serves over 80% of Brazil’s card acquirers and sub-acquirers. This article tells how we got here — and why Cloud Spanner is the centerpiece of this story.
What CERC Does (And Why It Matters)
CERC is a Financial Market Infrastructure (FMI) — one of the entities that form the foundation on which the Brazilian financial system operates. Our mission is to provide transparency and security to the registration, analysis, and settlement control of financial assets used as collateral in credit operations.
In practice, this means the following: when a merchant uses their credit card receivables as collateral to obtain a loan, it is CERC that registers, validates, and authenticates that operation. Without this centralized registry, the information asymmetry between creditors and debtors would make the credit market more expensive, slower, and riskier.
The scale of this work is significant. CERC processes receivables that underpin billions of reais in daily commerce. And the credit card receivables market is just one of the asset classes we register. Trade receivables, agribusiness receivables, and other categories follow the same path.
Why Cloud Native From the Start
When CERC was founded, one architectural decision defined everything that would follow: there would be no on-premise infrastructure. Zero. No racks, no private data centers, no hardware to scale manually.
This was not a trivial decision. We were building an FMI — a regulated entity of the financial system — and the market expectation was for traditional, controlled, and physically isolated environments. But the nature of the problem we solve demanded a different approach.
Before production operations began, there was no reliable way to estimate the transaction volume the market would demand. It could be thousands. It could be millions. Uncertainty was the only certainty. And in a scenario of uncertain scale, the cloud isn’t an option — it’s the only rational answer.
In practice, choosing Google Cloud was natural: we needed a partner with proven experience at massive scale, offering not just infrastructure but an ecosystem of managed services that allowed us to focus on the business problem — not on managing servers. CERC’s history evolved alongside Google Cloud, and this co-evolution shaped the architecture we have today.
The Architecture: Every Piece in Its Place
CERC’s infrastructure is composed of Google Cloud services that complement each other to meet simultaneous requirements of scale, consistency, availability, and security.
Cloud Spanner — The Transactional Heart
Cloud Spanner is the most critical piece of our architecture. It’s the database where receivables registration transactions happen — and where consistency is non-negotiable.
What makes Spanner unique in the market is something that, for a long time, was considered impossible in computer science: combining strong consistency (ACID) with unlimited horizontal scalability in a globally distributed database.
Traditional databases force you to choose: either you get strong consistency with limited scale (classic relational databases), or unlimited scale with eventual consistency (NoSQL databases). Spanner eliminates this trade-off.
For CERC, this translates into concrete capabilities:
- On-demand scaling: we increase and decrease processing power without stopping the environment. In a financial market where maintenance windows are unacceptable, this is fundamental.
- 99.999% availability: the famous “five nines” — less than 5 minutes of downtime per year. For an FMI that processes transactions supporting credit for millions of businesses, unavailability is not an option.
- Distributed ACID consistency: every transaction is atomic, consistent, isolated, and durable — even when data is distributed across multiple nodes. In a financial system, a partially applied transaction is worse than a failed one.
CERC didn’t start with Spanner. Initially, we used Cloud SQL — a managed relational database, perfectly adequate for early volumes. As the receivables market grew, migrating to Cloud Spanner was the decision that allowed us to scale without compromising transactional integrity.
In my experience, the moment we migrated to Spanner was a turning point. The confidence of knowing that the database scales horizontally without compromising transactional consistency changes how you design systems. You stop thinking about workarounds for infrastructure limitations and start thinking about the business problem.
BigQuery — The Analytics Layer
If Spanner is the transactional heart, BigQuery is the analytical nervous system. It’s where we process terabytes of data to generate insights, regulatory reports, and share information with other market players.
BigQuery enables CERC to offer transparency to the financial ecosystem — one of our core values. Receivables data processed and analyzed in BigQuery feeds everything from internal risk models to the reports required by Brazil’s Central Bank.
Google Kubernetes Engine (GKE) — The Application Layer
CERC’s entire application layer runs on microservices orchestrated by GKE. This gives us the flexibility to scale individual services independently, deploy without downtime, and maintain development agility even with a production system processing 100,000 transactions per second.
GKE is also where we serve our APIs, allowing market participants to integrate with CERC programmatically and at scale.
100,000 Transactions per Second
This is the number that defines the scale of the operation. 100,000 transactions per second — each one registering, validating, or querying receivables that represent real money from real businesses.
To put this in perspective: when the credit card receivables project went into production, there was no market benchmark for the volume that would be processed. The Central Bank’s regulation was clear on requirements, but the actual volume would only be known once the system was live.
CERC’s cloud native architecture — with Spanner scaling processing without downtime, GKE orchestrating microservices, and BigQuery handling the analytics layer — is what allows us to absorb this volume with stability. This isn’t an occasional peak. It’s normal operations.
And storage keeps pace: petabytes of data maintained, processed, and available for querying by market participants.
What It Means to Be an Innovative FMI
The Financial Market Infrastructure space is, by nature, conservative. FMIs are regulated entities that form the backbone of the financial system — and the general expectation is stability above all else.
CERC challenges that premise. Being cloud native from day zero, in a segment where on-premise was the standard, was an act of innovation. But innovation at CERC goes beyond infrastructure choices.
It’s about how we build software. It’s about having an engineering team that operates with autonomy, that uses the best tools in the market, that solves scale problems few companies in Brazil face. It’s about an environment where engineers work with Cloud Spanner, BigQuery, Kubernetes, Apache Airflow, autonomous AI agents — and where each of these technologies solves a real problem, not a resume requirement.
Day to day, this translates into solving problems that have no off-the-shelf solution. When Brazil’s Central Bank defined the rules for credit card receivables registration, there was no playbook for processing this volume at this level of criticality. The solution was built in-house — and it continues to evolve.
In my view, the next big leap lies in maximizing the value of the data we already have. Registering and storing isn’t enough — we need to extract intelligence, identify patterns, and generate value from the massive amount of information we process daily. Building this data culture in the Brazilian financial market is one of the goals that drives me, and the cloud is the foundation that makes it possible.
What Comes Next
Credit card receivables are just one class of receivables — representing roughly 15% of all receivables in the Brazilian economy. All other categories, including trade receivables, agribusiness receivables, and others, are following the same path toward digitization and centralized registration.
CERC’s vision is to transform all receivables in the economy into assets fully usable by their owners, so that this results in greater access to credit to fund business growth.
On this journey, exploring Apigee for an API-first model across the organization, leveraging Machine Learning for new services, and expanding analytical capacity with BigQuery are concrete investments being made.
The infrastructure is ready. The scale is proven. The next chapter is expanding the impact — and the cloud will be essential in that process.
Technologies
| Layer | Technology |
|---|---|
| Transactional database | Cloud Spanner |
| Analytical processing | BigQuery |
| Container orchestration | Google Kubernetes Engine (GKE) |
| API management | Apigee |
| Data orchestration | Apache Airflow (Cloud Composer) |
| Infrastructure | Google Cloud (100% cloud native) |
CERC is the financial market infrastructure that serves over 80% of Brazil’s card acquirers and sub-acquirers — 100,000 transactions per second, petabytes of data, zero on-premise infrastructure. If you want to work on real-scale problems, with cutting-edge technology and direct impact on the Brazilian financial system — we’re hiring.
This post was written by: Vitor Melon | Head of Engineering — Payment Arrangements Platform.