 |
| Bellacosa Mainframe e o caso da nuvem que evaporou |
☕ Um Café no Bellacosa Mainframe
CSI Las Vegas, COBOL e o Caso da Nuvem que Ficou sem Máquinas: quando o Nubank Cresceu até Encontrar os Limites Físicos da AWS
🔬 Datomic, Clojure, Kafka, Kubernetes, sharding, memória, garbage collection, Pangeia, Deriva Continental, 21 mil databases e a investigação do estranho incidente em que o suspeito parecia ser a AWS — até Grissom olhar para a arquitetura e perguntar: “Vocês disseram que a nuvem era infinita. Quem verificou isso?”
São 02h17.
Las Vegas continua acesa.
No laboratório do CSI, Gil Grissom observa silenciosamente uma fotografia ampliada.
Não há sangue.
Não há impressão digital.
Não há cartucho no chão.
Existe apenas uma mensagem:
INSUFFICIENT CAPACITY
Nick Stokes olha para a tela.
— AWS?
Grissom não responde.
Sara Sidle aproxima-se.
— Nubank.
— Quantos clientes?
— Milhões.
Na outra extremidade do laboratório, um velho programador COBOL bebe café diante de um terminal verde.
Ele ouve a conversa.
— Cloud?
Sara confirma.
— Cloud.
O veterano pergunta:
— E acabou recurso?
— Parece que sim.
Ele sorri.
— Então finalmente encontramos o datacenter.
Grissom vira lentamente a cabeça.
— Explique.
O COBOLzeiro coloca a caneca sobre a mesa.
CAFÉ
+
COBOL
=
EVIDÊNCIA
— A nuvem nunca desapareceu com o computador, senhor Grissom.
Pausa dramática.
— Ela apenas colocou o computador atrás de uma API.
YEEEEAAAAHHHH!
Óculos escuros.
Abertura.
☕
Hoje vamos investigar um dos episódios mais fascinantes da engenharia do Nubank: a afirmação, registrada pela própria engenharia da empresa, de que sua estratégia de crescimento chegou a enfrentar situações nas quais a AWS não tinha máquinas disponíveis suficientes para acompanhar o ritmo de scaling exigido pela arquitetura.
Não significa que o Nubank derrubou a Amazon.
Não significa que acabou EC2 no planeta.
E definitivamente não significa que Jeff Bezos encontrou uma fatura roxa e gritou:
S0C4
A história real é tecnicamente muito mais interessante.
🔬 EVIDÊNCIA 001 — A cena do crime começa em 2013
O Nubank foi fundado em 2013 e teve a vantagem — e também o desafio — de construir sua infraestrutura praticamente sem um legado bancário anterior.
Quando Lucas Cavalcanti entrou no Nubank, no fim de 2013, estava entre os primeiros engenheiros da empresa. O relato retrospectivo publicado pelo Nubank em 20 de agosto de 2025 conta que os sistemas iniciais foram construídos principalmente utilizando:
Clojure
+
Datomic
+
AWS
+
CloudFormation
+
AMI
Com o crescimento, vieram Docker, Kubernetes, microsserviços e posteriormente uma arquitetura de Core Banking preparada para múltiplos produtos e países.
10 anos de engenharia no Nubank — 20 de agosto de 2025
Isso já representa uma diferença gigantesca para o banco tradicional.
Um grande banco que começou décadas atrás normalmente acumulou algo parecido com:
CANAIS
|
MIDDLEWARE/APIs
|
+--------+--------+
| |
CICS IMS
| |
COBOL COBOL
| |
Db2/VSAM IMS DB
|
MQ
|
BATCH
O Nubank começou muito mais próximo de:
APP
|
APIs
|
MICROSERVICES
|
+---------+---------+
| |
DATOMIC KAFKA
| |
+---------+---------+
|
AWS
Não pense que um desenho é automaticamente superior ao outro.
São filosofias arquiteturais diferentes.
Mas ambas precisam responder à pergunta que assombra todo sistema financeiro:
O dinheiro chegou ao lugar certo, uma única vez, e consigo provar isso depois?
🔬 EVIDÊNCIA 002 — Clojure e Datomic
Agora Grissom encontra uma pista estranha.
(println "BANCO")
— O que é isso?
Moss, que inexplicavelmente entrou no episódio errado, responde:
— Clojure.
O COBOLzeiro olha.
— Por que tem tantos parênteses?
Clojure é uma linguagem funcional da família Lisp executada sobre JVM.
O Nubank fez dela uma tecnologia importante desde seus primeiros sistemas.
Mas ainda mais interessante é Datomic.
Datomic possui uma filosofia muito diferente da imagem clássica que o COBOLzeiro pode ter de um banco SQL.
Em um modelo simplificado:
UPDATE CONTA
SET SALDO = 800
WHERE CONTA = 123;
pensamos no estado atual.
Datomic enfatiza fortemente fatos e histórico.
Conceitualmente:
T0 → saldo 1000
T1 → compra -200
T2 → saldo 800
Isso combina maravilhosamente com outra ideia usada pelo Nubank:
Event Sourcing.
Em 11 de fevereiro de 2020, Gustavo Bicalho, então engenheiro de software do Nubank, publicou uma explicação detalhada sobre essa arquitetura.
Em vez de armazenar somente:
SALDO = 800
você pode preservar a sequência que produziu aquele estado:
CONTA CRIADA
|
v
+1000
|
v
-200
|
v
SALDO ATUAL = 800
Isso é extremamente interessante para sistemas financeiros porque histórico, auditoria e reconstrução de estado são requisitos naturais do domínio.
Uma floresta digital: o cache perene — 11 de fevereiro de 2020
🔬 EVIDÊNCIA 003 — O Datomic separa responsabilidades
Aqui precisamos abrir o corpo.
Metaforicamente, naturalmente.
Datomic separa responsabilidades que normalmente imaginamos reunidas em um servidor de banco de dados.
Simplificando:
DATOMIC
WRITE
|
v
TRANSACTOR
|
v
STORAGE
^
|
+----------+----------+
| | |
PEER PEER PEER
| | |
QUERY QUERY QUERY
Isso oferece características extremamente interessantes.
Mas havia uma pista escondida:
memória.
Os peers podiam manter informações em cache para responder rapidamente às consultas.
Quanto mais dados...
mais cache.
Quanto mais clientes...
mais dados.
Quanto mais requisições...
mais trabalho.
O que poderia dar errado?
Grissom olha para a câmera.
Tudo.
🔬 EVIDÊNCIA 004 — O primeiro cadáver: memória
O artigo de 11 de fevereiro de 2020 registra exatamente o problema.
As máquinas começaram a apresentar:
OUT OF MEMORY
E longas pausas de:
GARBAGE COLLECTION
A primeira reação foi perfeitamente compreensível.
PROBLEMA: MEMÓRIA
SOLUÇÃO:
ADD MORE MEMORY
Funcionou.
Por algum tempo.
Então voltou.
Aumentaram novamente.
Funcionou.
Até que chegaram a instâncias na casa dos 100 GB de memória, segundo o relato técnico, e ainda estavam operando perigosamente próximas do limite.
O velho sysprog olha para Grissom.
— Scale-up.
— Traduza.
— Máquina maior.
32 GB
|
v
64 GB
|
v
100 GB
|
v
???
Existe um problema fundamental.
Não importa quanto dinheiro você tenha.
Em algum ponto:
BIGGEST-MACHINE-AVAILABLE
é realmente a maior máquina disponível.
🔬 EVIDÊNCIA 005 — Por que tanta memória?
A investigação encontrou duas causas particularmente interessantes.
Primeiro, o modelo baseado em eventos exigia carregar bastante informação para o cache em memória dos peers.
Segundo, qualquer instância do serviço poderia receber uma determinada requisição.
Imagine que o mesmo cliente consulta seu saldo quatro vezes.
Poderíamos ter:
REQUEST 1 → INSTANCE A → LOAD CUSTOMER
REQUEST 2 → INSTANCE B → LOAD CUSTOMER
REQUEST 3 → INSTANCE C → LOAD CUSTOMER
REQUEST 4 → INSTANCE D → LOAD CUSTOMER
Quatro máquinas podem acabar fazendo trabalho semelhante.
O próprio artigo técnico descreve esse desperdício: diferentes instâncias carregando repetidamente dados relacionados aos mesmos clientes.
O problema não era simplesmente:
PRECISAMOS DE MAIS RAM
Era:
NOSSO MODELO DE DISTRIBUIÇÃO
FAZ MUITAS MÁQUINAS
REPETIREM TRABALHO
Isso muda completamente o diagnóstico.
CSI chama isso de:
encontrar a causa da morte.
Mainframe chama de:
parar de aumentar REGION e descobrir quem está comendo storage.
🔬 EVIDÊNCIA 006 — 2016: entra o sharding
Segundo a retrospectiva técnica publicada pelo Nubank em 20 de agosto de 2025, o sharding começou a ser introduzido em 2016.
A ideia é dividir.
Em vez de:
TODOS
|
v
+-----------+
| DATABASE |
+-----------+
temos conceitualmente:
CLIENTES
|
+-----------+-----------+
| | |
v v v
SHARD A SHARD B SHARD C
Cada shard responde por uma parcela.
Não sabemos que critério específico é utilizado em todos os sistemas do Nubank, portanto não devemos inventá-lo.
Mas imagine didaticamente:
CLIENTES 000-299 → SHARD A
CLIENTES 300-599 → SHARD B
CLIENTES 600-999 → SHARD C
Agora você pode crescer adicionando shards.
SCALE-UP
BIGGER
|
v
BIGGER MACHINE
vira:
SCALE-OUT
SHARD 1
SHARD 2
SHARD 3
SHARD 4
SHARD 5
Essa mudança é gigantesca.
🔬 EVIDÊNCIA 007 — E então o suspeito vira AWS
O sharding resolveu o problema?
Sim.
Temporariamente.
Essa palavra deveria estar impressa na parede de todo departamento de arquitetura.
NO SOLUTION SCALES FOREVER.
O Nubank continuou crescendo.
A retrospectiva publicada em 2025 relata explicitamente que as soluções de sharding implantadas a partir de 2016 funcionaram durante algum tempo, mas acabaram encontrando limites físicos, inclusive situações nas quais a AWS ficou sem máquinas disponíveis suficientes para acompanhar o ritmo de scaling exigido pelo Nubank.
É aqui que nasceu a história:
“O Nubank quebrou a AWS.”
CSI pede perícia.
Resultado:
AWS GLOBAL OUTAGE ............ NÃO
AWS INTEIRA ESGOTADA ......... NÃO
INTERNET DESTRUÍDA ........... NÃO
CAPACIDADE REQUERIDA
PELO MODELO DE SCALING ....... SIM
A diferença é enorme.
🔬 EVIDÊNCIA 008 — Cloud não é magia
Abra uma instância EC2.
Atrás dela existe:
DATACENTER
|
+-- RACK
|
+-- SERVER
|
+-- CPU
+-- RAM
+-- NIC
+-- STORAGE
Existe eletricidade.
Refrigeração.
Processadores.
Memória.
Rede.
Capacidade.
Cloud é uma extraordinária camada de abstração sobre tudo isso.
Mas:
CLOUD != INFINITE
Se você precisa de uma determinada família de máquinas, em determinada região, com determinada configuração e em grande quantidade, existe capacidade física por trás dessa solicitação.
É por isso que capacity planning não morreu.
Ele apenas colocou camiseta, tênis e começou a falar inglês.
🔬 EVIDÊNCIA 009 — Quotas também existem
Existe outro limite além do hardware.
Quotas.
Em 9 de abril de 2025, o Nubank publicou uma análise dedicada justamente à gestão dos limites da nuvem.
Naquela data, a empresa relatava operar:
+4.000 microsserviços
dezenas de milhares de pods
72 bilhões de eventos Kafka por dia
milhões de requisições por segundo
Tudo orquestrado em enorme escala.
Gerenciando limites na nuvem — 9 de abril de 2025
Existem quotas envolvendo diferentes recursos AWS.
Então capacity engineering passa a perguntar:
QUANTO TEMOS?
QUANTO USAMOS?
QUAL A TAXA DE CRESCIMENTO?
QUANDO CHEGAMOS AO LIMITE?
QUAL LIMITE PODE SER AUMENTADO?
QUAL LIMITE EXIGE REDESIGN?
O velho sysprog levanta a mão.
— Isso é capacity planning.
Silêncio constrangedor.
— Sim.
Ele volta para o café satisfeito.
🔬 EVIDÊNCIA 010 — Pangeia
Agora encontramos um Easter egg maravilhoso.
No começo, boa parte da infraestrutura estava concentrada em poucas e enormes contas AWS.
Internamente o Nubank chamou isso de:
Pangeia.
Sim.
O supercontinente pré-histórico.
PANGEIA
+---------------------------+
| AWS ACCOUNT |
| |
| service service service |
| kafka kubernetes datomic |
| service service service |
| |
| TODO MUNDO AQUI |
+---------------------------+
Enquanto a empresa era menor, isso era administrável.
Com crescimento gigantesco, surgiram problemas.
Um incidente pequeno poderia ter um blast radius grande.
Separar staging de produção ficava mais difícil.
Deployments podiam ser prejudicados.
Quotas compartilhadas tornavam-se um problema.
A arquitetura tinha criado um supercontinente tecnológico.
Grissom observa o mapa.
— Continentes se movem.
O arquiteto responde:
— Exatamente.
🔬 EVIDÊNCIA 011 — Deriva Continental
A solução ganhou outro nome fantástico:
Continental Drift — Deriva Continental.
Em vez de:
PANGEIA
|
TUDO CONECTADO
passaram para uma estratégia multi-account:
ACCOUNT A
|
DOMAIN A
ACCOUNT B
|
DOMAIN B
ACCOUNT C
|
DOMAIN C
Isso melhora isolamento.
Agora um problema em:
DOMAIN A 💥
não significa necessariamente:
A 💥
B 💥
C 💥
D 💥
TODO MUNDO 💥
O blast radius diminui.
É uma ideia fundamental de resiliência:
não tente apenas impedir falhas; limite o tamanho da destruição quando elas inevitavelmente acontecerem.
Esse princípio vale para AWS.
Vale para Kubernetes.
Vale para CICS.
Vale para Parallel Sysplex.
Vale para compartimentos estanques de navios.
E vale para CSI quando Hodges resolve experimentar alguma substância misteriosa no laboratório.
🔬 EVIDÊNCIA 012 — Sharding virou filosofia
A parte mais interessante é que sharding deixou de ser apenas:
DIVIDIR DATABASE
e passou a influenciar diferentes camadas.
A infraestrutura descrita pelo Nubank envolve particionamento de serviços, Datomic, Kafka e outros componentes para evitar que um único domínio de capacidade vire gargalo.
Conceitualmente:
TRAFFIC
|
+-----------------+-----------------+
| | |
v v v
SHARD A SHARD B SHARD C
| | |
SERVICES A SERVICES B SERVICES C
| | |
DATOMIC A DATOMIC B DATOMIC C
| | |
KAFKA A KAFKA B KAFKA C
Agora crescer pode significar:
ADD SHARD
em vez de:
PROCURE UMA MÁQUINA MAIOR
Essa é uma mudança arquitetural profunda.
🔬 EVIDÊNCIA 013 — 450 milhões de eventos de fraude por dia
Agora o CSI encontra os números que explicam por que tudo isso é necessário.
Na plataforma de análise de risco e fraude, o Nubank divulgou números impressionantes:
~450 milhões de eventos/dia
~5 milhões de requisições internas/minuto
20 shards somente no Brasil
Um único evento, como uma transação Pix, pode desencadear dezenas de processos subsequentes. A stack divulgada para essa plataforma inclui Clojure, Datomic sobre DynamoDB, Kafka e modelos de machine learning em Python, além de logs, traces e métricas em tempo real.
Como o Nubank escalou sua plataforma de defesa contra fraudes
Imagine:
PIX
|
+---------+---------+
| | |
RISCO FRAUDE IDENTIDADE
| | |
ML RULES DEVICE
| | |
+---------+---------+
|
ACTION
Uma operação do cliente não corresponde necessariamente a uma operação interna.
Pode produzir dezenas.
Essa é uma lição fundamental.
Cliente não é unidade de capacidade.
A unidade real pode ser:
EVENTOS
REQUISIÇÕES
TPS
CPU
MEMÓRIA
I/O
NETWORK
STORAGE
🔬 EVIDÊNCIA 014 — 21 mil databases
E então encontramos uma evidência datada de 1º de julho de 2026.
O Nubank informou operar mais de 21 mil databases em produção, distribuídos entre Brasil, México e Colômbia.
Ainda mais curioso: a camada central de bancos de dados é administrada diretamente por uma equipe de apenas cinco engenheiros, apoiada por automação, governança e ownership distribuído entre as equipes.
Como o Nubank opera mais de 21 mil databases — 1º de julho de 2026
COBOLzeiro:
— VINTE E UM MIL?
Sim.
Mas cuidado.
Não pense:
21.000 Db2 Subsystems gigantescos
Microserviços alteram completamente a granularidade.
Muitos serviços possuem seu próprio armazenamento.
O número ilustra outra realidade:
nessa escala, operação manual morreu.
Você não pode ter alguém abrindo terminal e configurando 21 mil databases artesanalmente.
Precisa de:
AUTOMATION
+
POLICY
+
SELF-SERVICE
+
OBSERVABILITY
+
GOVERNANCE
🔬 EVIDÊNCIA 015 — Mainframe versus cloud
Agora Grissom coloca as duas arquiteturas lado a lado.
Filosofia mainframe
IBM Z
|
+---------+---------+
| | |
CICS Db2 IMS
| | |
COBOL DATA DATA
|
MQ
|
JES
Grande capacidade vertical.
Integração profunda.
Centralização.
Controle extraordinário.
Alta confiabilidade.
Filosofia cloud-native
CLOUD
|
KUBERNETES
|
+----------+----------+
| | |
SERVICE A SERVICE B SERVICE C
| | |
DATA A DATA B DATA C
|
EVENTS
Mais distribuição.
Mais componentes.
Mais scale-out.
Mais independência.
Mas também mais rede.
Mais observabilidade.
Mais pontos potenciais de falha.
Não existe almoço grátis.
🔬 EVIDÊNCIA 016 — O COBOLzeiro já conhece metade desses problemas
Faça a tradução:
MAINFRAME CLOUD
CPU vCPU
storage storage
WLM scheduler/autoscaling
SMF/RMF observability
MQ Kafka/event streaming
RACF IAM
LPAR isolation
capacity planning capacity engineering
chargeback FinOps
Essas não são equivalências técnicas perfeitas.
Mas são ótimas pontes mentais.
O iniciante COBOL começa a perceber:
Cloud não inventou disponibilidade, workload, segurança, capacity e auditoria.
Criou novas maneiras de resolvê-los.
🔬 EVIDÊNCIA 017 — Passo a passo para estudar esse caso
Se você está começando COBOL, estude nesta ordem.
1. Aprenda transações.
COMMIT
ROLLBACK
ACID
LOCK
RECOVERY
2. Aprenda CICS.
Entenda task, transaction, program e region.
3. Aprenda Db2.
Entenda buffer, log, index, isolamento e recuperação.
4. Aprenda MQ.
Depois Kafka fica muito mais compreensível.
5. Estude scale-up versus scale-out.
MAQUINA MAIOR
versus:
MAIS MÁQUINAS
6. Aprenda sharding.
Pergunte sempre:
Qual é a chave de particionamento?
7. Estude Kubernetes.
Mas entenda primeiro o problema que ele resolve.
8. Estude observabilidade.
LOGS
METRICS
TRACES
Compare mentalmente com SMF, RMF e traces dos subsistemas.
9. Estude FinOps e capacity.
Porque:
CLOUD RESOURCE
continua significando:
DINHEIRO
10. Faça sempre a pergunta CSI:
Qual é a causa raiz?
Não aceite:
PRECISA MAIS MEMÓRIA
antes de descobrir:
POR QUE PRECISA MAIS MEMÓRIA?
🔬 EVIDÊNCIA FINAL — Então Nubank quebrou a AWS?
Grissom reúne a equipe.
Quadro branco.
Fotos.
Diagramas.
Logs.
A conclusão aparece:
CAUSA DA MORTE:
NÃO FOI AWS DOWN.
NÃO FOI "CLOUD ACABOU".
FOI UMA ARQUITETURA EM HIPERCRESCIMENTO
ENCONTRANDO LIMITES FÍSICOS
DE SUA ESTRATÉGIA DE ESCALA.
O sharding introduzido em 2016 ajudou.
Depois precisou evoluir.
Pangeia precisou fragmentar-se.
Vieram múltiplas contas.
Deriva Continental.
Mais isolamento.
Mais automação.
Mais sharding.
Kubernetes.
Kafka.
Datomic.
Capacity engineering.
Observabilidade.
E uma mudança filosófica fundamental:
NÃO PROCURE
UMA MÁQUINA INFINITA.
CONSTRUA UM SISTEMA
QUE NÃO PRECISE DELA.
☕ Epílogo — 03h42 no laboratório
O caso está encerrado.
Sara guarda as evidências.
Nick fecha o notebook.
Grissom encontra o COBOLzeiro ainda diante do terminal.
— Então o que você aprendeu?
O veterano pensa.
— Que cloud é impressionante.
— Só isso?
— Não.
Ele olha para o diagrama:
CLOJURE
|
DATOMIC
|
KAFKA
|
KUBERNETES
|
AWS
Depois olha para:
COBOL
|
CICS
|
DB2
|
MQ
|
IBM Z
— Mudaram quase todas as ferramentas.
— E?
— Os problemas continuam vindo ao mesmo laboratório.
Grissom sorri.
Disponibilidade.
Consistência.
Capacidade.
Memória.
Concorrência.
Performance.
Segurança.
Auditoria.
Recuperação.
Custos.
Falhas.
O COBOLzeiro termina o café.
— Há quarenta anos alguém pergunta:
QUANTO AINDA CABE?
Hoje o cloud engineer pergunta exatamente a mesma coisa.
Só mudou o dashboard.
Ele se levanta.
Na tela aparece uma última mensagem:
CASE CLOSED.
E abaixo:
CLOUD IS SOMEONE ELSE'S
CAPACITY PLANNING PROBLEM.
UNTIL IT BECOMES YOURS.
☕ Fim do café.
