Bellacosa Mainframe e os 20mil datoms submarinos

☕ Um Café no Bellacosa Mainframe

Vinte Mil Datoms Submarinos: COBOL, Datomic e a Viagem ao Centro de um Banco de Dados que Decidiu que `UPDATE` Era uma Ideia Suspeita

🌊 Clojure, Rich Hickey, Cognitect, Nubank, Datalog, EAVT, imutabilidade, transações ACID, Transactor, peers, caches, AWS, DynamoDB e a extraordinária viagem de um COBOLzeiro acostumado a VSAM, IMS, Adabas e Db2 até uma máquina de 2012 que parecia ter sido trazida do futuro pelo capitão Nemo

Nota do diário de bordo — 2012
Existem momentos na história da tecnologia em que alguém olha para aquilo que todos fazem há décadas e comete a inconveniência de perguntar:
“Mas por que fazemos assim?”
Normalmente essa pessoa é convidada a parar de atrapalhar a reunião.
Às vezes ela cria Clojure.
Depois cria Datomic.

Se Júlio Verne tivesse trabalhado com bancos de dados, talvez Vinte Mil Léguas Submarinas começasse numa sala de processamento.

O professor Pierre Aronnax seria um programador COBOL.

Conseil seria DBA.

Ned Land provavelmente trabalharia em Produção.

E o capitão Nemo surgiria diante de uma máquina desconhecida dizendo:

— Senhores, apresento-lhes o Datomic.

O COBOLzeiro examinaria cuidadosamente o equipamento.

— Onde estão minhas tabelas?

— Não pense em tabelas.

— Onde está o UPDATE?

— Não precisamos pensar dessa maneira.

— Onde fica o servidor de banco?

— É complicado.

— Qual linguagem?

— Clojure.

Silêncio.

— Podemos voltar para o barco?

Não.

Já mergulhamos.

E estamos indo fundo.

⚓ Capítulo I — O monstro desconhecido

Para entender por que Datomic parece tão alienígena, precisamos lembrar o mundo em que apareceu.

Era 2012.

Oracle, Db2, SQL Server e PostgreSQL já eram tecnologias extremamente estabelecidas.

MongoDB havia aparecido em 2009.

Cassandra crescia.

Hadoop estava em plena ascensão.

A palavra NoSQL estava por toda parte.

A discussão frequentemente parecia:

RELACIONAL
    │
    │ ACID
    │ SQL
    │ schema
    │ joins
    ▼

       versus

NoSQL
    │
    │ scale-out
    │ distribuição
    │ schema flexível
    │ eventual consistency
    ▼

E no meio dessa batalha aparece uma criatura estranha.

Em março de 2012, a equipe da então Relevance, depois Cognitect, apresentou Datomic ao público. A tecnologia estava profundamente ligada a Rich Hickey, criador da linguagem Clojure. A própria Cognitect contou posteriormente que a equipe havia trabalhado por quase dois anos para transformar a visão de Hickey em um banco de dados.

A edição gratuita apareceria em junho daquele mesmo ano.

Não era IBM.

Não era Oracle.

Não era Microsoft.

Não era uma universidade produzindo um protótipo acadêmico.

Era uma empresa relativamente pequena propondo:

Talvez estejamos decompondo bancos de dados de maneira errada.

O COBOLzeiro experiente imediatamente pergunta:

“E quem decidiu colocar dinheiro de cliente nisso?”

Calma.

Chegaremos lá.

🌊 Capítulo II — Antes de mergulhar, consulte os mapas antigos

Para quem começou diretamente com PostgreSQL ou MySQL, Datomic pode parecer completamente extraterrestre.

Para quem conhece a história dos bancos de dados, nem tanto.

Nossa viagem começa muito antes.

VSAM
 │
 ▼
IMS
 │
 ▼
ADABAS
 │
 ▼
RELACIONAL / DB2
 │
 ▼
DATOMIC

Cada tecnologia respondeu de maneira diferente à pergunta:

O que é um dado e como chegamos até ele?

🗃️ VSAM — encontre o registro

No VSAM KSDS você pensa naturalmente:

KEY
 │
 ▼
INDEX
 │
 ▼
CONTROL AREA
 │
 ▼
CONTROL INTERVAL
 │
 ▼
RECORD

Quer o cliente 12345?

Procure a chave.

O mundo ainda está muito próximo do armazenamento físico.

O programador conhece:

KSDS
ESDS
RRDS
LDS

E aprende rapidamente uma verdade eterna:

A maneira como organizamos dados influencia brutalmente a maneira como conseguimos acessá-los.

Guarde essa frase.

Ela voltará quando encontrarmos:

EAVT
AEVT
AVET
VAET

🌳 Capítulo III — IMS constrói uma árvore no fundo do oceano

IMS oferece outro universo.

CLIENTE
   │
   ├── CONTA
   │     │
   │     └── MOVIMENTO
   │
   └── ENDEREÇO

Hierarquia.

Parent.

Child.

Segmentos.

DL/I.

Agora o programador precisa entender:

Qual é o caminho até meu dado?

O banco não precisa ser uma coleção de tabelas.

Esse detalhe será importante daqui a pouco.

🧙 Capítulo IV — ADABAS aparece com seus descritores

Então encontramos Adabas.

Outra filosofia.

Temos conceitos como:

FILE
FIELD
ISN
DESCRIPTOR
SUPERDESCRIPTOR

A estrutura física e a maneira lógica de localizar informações tornam-se novamente interessantes.

Nosso viajante aprende outra lição:

A visão apresentada à aplicação não precisa reproduzir literalmente a organização física.

Portanto, quando Datomic disser:

ENTITY
ATTRIBUTE
VALUE
TRANSACTION

um veterano pode estranhar.

Mas não deveria entrar em pânico.

Já vimos criaturas mais estranhas.

🏛️ Capítulo V — Db2 e a grande revolução declarativa

Então chega o modelo relacional.

Agora você pode escrever:

SELECT NOME, SALDO
FROM CONTA
WHERE CLIENTE = 12345;

Observe a revolução.

Você não disse:

vá para CI
localize índice
ande três registros
encontre ponteiro

Você disse:

Quero isto.

O otimizador decide como encontrar.

Essa abstração foi monumental.

Mas nosso cérebro passou décadas construindo outra imagem:

TABLE
  │
  ├── ROW
  ├── ROW
  ├── ROW
  └── ROW

E depois:

UPDATE CONTA
SET SALDO = 800
WHERE CLIENTE = 12345;

Antes:

SALDO = 1000

Depois:

SALDO = 800

Naturalmente Db2 possui logging, recovery, temporal tables, auditoria e uma enorme infraestrutura para preservar e reconstruir estados.

Mas nosso modelo mental da aplicação normalmente continua:

ESTADO ANTIGO
     │
   UPDATE
     │
     ▼
ESTADO NOVO

É justamente aqui que o Nautilus aparece.

🐙 Capítulo VI — Capitão Rich Hickey pergunta: “Por que destruir o passado?”

Rich Hickey vem do mundo da programação funcional.

Uma de suas grandes obsessões intelectuais é estado e identidade ao longo do tempo.

Em vez de:

X = 10

X = 20

X = 30

pense:

X em T1 = 10
X em T2 = 20
X em T3 = 30

Parece uma pequena mudança.

Não é.

É a entrada para o submarino.

Datomic leva essa ideia para o banco de dados.

Em vez de pensar primordialmente:

“O banco é um conjunto de registros que vou modificando.”

pense:

“O banco acumula fatos ao longo do tempo.”

A documentação oficial descreve Datomic justamente em torno de database values imutáveis e informação acumulada transacionalmente.

Documentação oficial do Datomic

🔬 Capítulo VII — Descobrimos o Datom

A unidade fundamental é o:

DATOM

Conceitualmente:

E A V Tx Added?

Onde:

E  = Entity
A  = Attribute
V  = Value
Tx = Transaction

Imagine:

[1001 :cliente/nome "Arthur Dent" 5001 true]

Leia:

Na transação 5001 foi afirmado que a entidade 1001 possui nome Arthur Dent.

Outro:

[1001 :cliente/limite 5000 5002 true]

Depois o limite muda.

Não precisamos imaginar simplesmente:

5000 → destruído
8000 → colocado no lugar

Podemos representar conceitualmente:

T1

CLIENTE 1001
LIMITE 5000

Depois:

T2

RETRACT
CLIENTE 1001
LIMITE 5000

ASSERT
CLIENTE 1001
LIMITE 8000

Agora Datomic conhece:

T1 → 5000
T2 → 8000

O passado continua fazendo parte da história.

⏰ Capítulo VIII — O banco possui uma máquina do tempo

Aqui Júlio Verne provavelmente pediria licença para escrever outro livro.

Imagine uma auditoria.

— Qual é o limite do cliente?

R$ 8.000

— Qual era ontem?

R$ 5.000

— E antes?

R$ 3.000

Datomic possui conceitos como:

as-of
since
history

que permitem trabalhar naturalmente com diferentes visões temporais do database.

Isso produz uma imagem maravilhosa:

DATABASE T0
     │
     ▼
DATABASE T1
     │
     ▼
DATABASE T2
     │
     ▼
DATABASE T3

Você está em T3.

Mas pode perguntar como o mundo era em T1.

Para finanças, auditoria e investigação, isso é sedutor.

💰 Capítulo IX — “Agora entendi por que um banco gostou disso”

Exatamente.

Bancos vivem de perguntas temporais.

Qual era o saldo?

Quando mudou?

Qual regra estava vigente?

Quando o limite foi alterado?

Que informação conhecíamos naquele momento?

Qual transação introduziu esse fato?

Datomic torna o tempo parte fundamental do modelo.

Mas atenção!

Isso não significa automaticamente que Datomic seja melhor que Db2 para bancos.

Db2 possui recursos temporais, logs, auditoria, recovery, CDC e décadas de engenharia financeira.

A diferença interessante é filosófica:

DATOMIC

TEMPO + IMUTABILIDADE
        │
        ▼
estão no coração
do modelo

🧭 Capítulo X — Mas quem teve coragem de escolher isso?

E aqui chegamos ao Nubank.

Quando uma instituição tradicional escolhe um database, normalmente existe um questionário quase jurássico:

Quantos bancos usam?

Há quanto tempo existe?

Quem fornece suporte?

Quantos DBAs existem?

Tem HA?

Tem DR?

Tem backup?

Tem recovery?

Tem ferramentas?

Tem referência?

Quem atende domingo às 03:00?

E essas perguntas são excelentes.

Agora imagine Datomic por volta de 2014:

Datomic
lançamento: 2012
ecossistema: pequeno
Clojure
Cognitect
Datalog
modelo incomum

COBOLzeiro:

“Vocês perderam completamente o juízo?”

😂

Mas Nubank possuía uma vantagem gigantesca:

não havia legado.

Uma instituição tradicional começa:

NOVO SISTEMA
     │
     ▼
40 ANOS DE HISTÓRIA
     │
 ┌───┼────┐
 │   │    │
CICS DB2 IMS
 │   │    │
COBOL MQ  BATCH

Uma startup começa muito mais perto de:

┌───────────────────┐
│                   │
│       VAZIO       │
│                   │
└───────────────────┘

Ela pode perguntar:

Se começássemos agora, o que escolheríamos?

Essa liberdade permitiu escolhas muito mais ousadas.

🧬 Capítulo XI — Clojure entra no submarino

E aqui finalmente chegamos à linguagem que assustou nosso COBOLzeiro.

Clojure é uma linguagem funcional da família Lisp criada por Rich Hickey.

Você encontra:

(+ 1 2)

COBOLzeiro:

— Por que o operador está antes dos números?

Capitão Nemo:

— Continue.

Depois:

(when (> saldo limite)
  (bloquear-conta conta))

— Certo. Estranho, mas sobrevivo.

Então aparecem funções, estruturas persistentes, composição e imutabilidade.

A ideia central começa a emergir:

COBOL IMPERATIVO

ESTADO A
   │
 MOVE
 COMPUTE
 ADD
 SUBTRACT
   │
   ▼
ESTADO B

Clojure favorece pensar:

VALOR A
   │
 FUNÇÃO
   │
   ▼
VALOR B

Sem necessariamente destruir A.

Agora coloque Datomic ao lado:

CLOJURE
    │
    ▼
IMUTABILIDADE
    │
    ▼
VALORES
    │
    ▼
DATOMIC
    │
    ▼
FATOS
    │
    ▼
TEMPO

De repente Clojure + Datomic deixam de parecer um casamento acidental.

São parentes intelectuais.

🗺️ Capítulo XII — Datalog: SQL desapareceu!

O COBOLzeiro pergunta:

— Certo. Quero fazer um SELECT.

Capitão Nemo:

— Datalog.

— Um quê?

Uma query pode parecer:

[:find ?nome
 :where
 [?e :cliente/nome ?nome]]

Leia:

encontre valores ?nome onde exista uma entidade ?e cujo atributo :cliente/nome tenha esse valor.

Conceitualmente:

SELECT NOME
FROM CLIENTE;

Outra:

[:find ?nome
 :where
 [?e :cliente/nome ?nome]
 [?e :cliente/status :ativo]]

Aproximadamente:

SELECT NOME
FROM CLIENTE
WHERE STATUS = 'ATIVO';

Não tente transformar Datalog em SQL palavra por palavra.

Aprenda a lógica.

🧭 Capítulo XIII — Quatro bússolas: EAVT, AEVT, AVET, VAET

Agora nosso velho conhecimento de VSAM retorna triunfante.

Datomic mantém diferentes ordenações dos datoms:

EAVT
AEVT
AVET
VAET

Pense:

E = ENTITY
A = ATTRIBUTE
V = VALUE
T = TRANSACTION

EAVT:

ENTITY
 ATTRIBUTE
  VALUE
   TRANSACTION

Bom para perguntar:

O que sabemos sobre esta entidade?

AVET:

ATTRIBUTE
 VALUE
  ENTITY
   TRANSACTION

Interessante quando buscamos entidades através de valores indexados.

O velho VSAMzeiro sorri.

“Ahhhhh. Diferentes caminhos ordenados para chegar aos dados.”

Não é VSAM.

Mas o cérebro encontrou uma ponte.

⚙️ Capítulo XIV — Onde está o database server?

Agora começa a parte realmente Verne.

No Datomic Pro clássico, temos algo como:

                    TRANSACTOR
                        │
                     WRITES
                        │
                        ▼
                     STORAGE
                    ↗       ↖
                   /         \
                PEER         PEER
                 │             │
               QUERY         QUERY
                 │             │
               CACHE         CACHE

O Transactor coordena as transações.

Os Peers podem executar consultas próximos/dentro dos processos das aplicações.

O Storage persiste informação.

É uma decomposição diferente daquela imagem clássica:

APPLICATION
     │
     ▼
DATABASE SERVER
     │
     ▼
DISK

🔐 Capítulo XV — ACID continua a bordo

Datomic não respondeu ao problema de escala dizendo:

“Consistência é superestimada.”

Ele mantém transações ACID.

A — Atomicity
C — Consistency
I — Isolation
D — Durability

E mantém uma ordem transacional.

Para um sistema financeiro isso é extremamente relevante.

Mas aqui aparece a primeira grande limitação arquitetural que nosso dinossauro imediatamente detectaria.

🚨 Capítulo XVI — “Onde está o gargalo?”

Leituras podem escalar horizontalmente através de peers/compute.

              STORAGE

       ↙         ↓         ↘

    PEER       PEER       PEER
      │          │          │
    READ       READ       READ

Bonito.

Mas as escritas precisam respeitar a coordenação transacional.

Então:

READS
  │
  ├── PEER
  ├── PEER
  ├── PEER
  └── PEER

podem escalar muito bem

Enquanto:

WRITES
  │
  ▼
ordenação transacional

O COBOLzeiro levanta a mão.

— Qual é o limite de escrita?

Excelente pergunta.

Muito melhor que perguntar simplesmente:

“Quantos terabytes suporta?”

🧠 Capítulo XVII — CPU × memória × storage

Aqui voltamos ao capacity planning.

Datomic pode possuir uma base muito maior que a memória disponível porque trabalha com índices segmentados e camadas de cache.

Portanto:

DATABASE SIZE ≠ REQUIRED RAM

Imagine:

DATABASE = 20 TB

WORKING SET = 15 GB

CACHE/RAM = 64 GB

Potencialmente excelente.

Grande parte daquilo que a aplicação toca frequentemente cabe próximo da CPU.

Agora:

DATABASE = 2 TB

WORKING SET = 1,5 TB

CACHE/RAM = 64 GB

Problema.

QUERY
  │
  ▼
CACHE MISS
  │
  ▼
CACHE MISS
  │
  ▼
STORAGE
  │
  ▼
LATENCY

Portanto, a pergunta correta não é:

“Qual é o tamanho da base?”

É:

“Qual é o working set?”

Um veterano de buffer pool já ouviu música semelhante.

🧊 Capítulo XVIII — A imutabilidade produz caches deliciosos

Cache tradicional possui um problema clássico:

DATABASE = X
CACHE    = X

DATABASE muda para Y

CACHE continua X

OPS.

Precisamos invalidar.

Atualizar.

Sincronizar.

Datomic possui segmentos imutáveis.

Um segmento histórico que era correto continua correto.

Isso produz:

IMMUTABILITY
     │
     ▼
CACHE SEGURO
     │
     ▼
LOCALITY
     │
     ▼
READ PERFORMANCE

É uma consequência extremamente elegante da arquitetura.

🗄️ Capítulo XIX — Mas imutabilidade cobra aluguel no storage

Nada é grátis.

Imagine:

Se você preserva história, está armazenando mais informação.

Além disso, Datomic mantém diferentes índices dos datoms.

Portanto:

MAIS HISTÓRIA
      +
MAIS INDEXAÇÃO
      =
MAIS STORAGE

Isso é intencional.

A filosofia poderia ser resumida:

Storage é relativamente barato; perder conhecimento sobre o passado pode ser caríssimo.

Em finanças, essa frase ganha outro peso.

🏎️ Capítulo XX — E a indexação precisa acompanhar o submarino

Transações produzem novos datoms.

Simplificando:

TRANSACTIONS
      │
      ▼
MEMORY INDEX
      │
      ▼
BACKGROUND INDEXING
      │
      ▼
PERSISTENT INDEX

Agora imagine:

ENTRADA DE NOVOS DATOMS
         >
CAPACIDADE DE INDEXAÇÃO

O memory index começa a crescer.

Se isso continuar, Datomic precisa exercer back pressure, reduzindo a capacidade de aceitar novas transações enquanto a indexação recupera terreno.

Eis uma lição universal:

Você não pode escrever eternamente mais rápido do que consegue organizar aquilo que escreveu.

Nem no Nautilus.

Nem na AWS.

Nem no z17.

☁️ Capítulo XXI — A AWS entra na expedição

Datomic Cloud utiliza serviços da AWS para diferentes funções, incluindo tecnologias como DynamoDB e S3, além de camadas de compute/cache. A arquitetura oficial detalha essa separação.

Isso permite explorar:

DURABILITY
     │
     ▼
STORAGE

+

COMPUTE
     │
     ▼
CACHE / QUERY

Mas lembre-se:

cloud não aboliu capacity planning.

Ela apenas mudou o formulário de compra.

Antigamente:

PRECISO DE CPU

↓
capacity planning
↓
hardware
↓
instalação

Cloud:

PRECISO DE CPU

↓
API

↓
FATURA

A física continua lá.

🐘 Capítulo XXII — Até onde uma base Datomic pode crescer?

A resposta correta não é um número mágico.

Não existe:

DATOMIC MAXIMUM =
37,42 TB

que resolva nossa arquitetura.

Precisamos analisar:

database size
+
datom count
+
working set
+
write rate
+
read rate
+
query complexity
+
cache hit ratio
+
indexing rate
+
storage latency
+
CPU
+
RAM
+
GC
+
data model

Portanto:

CAPACITY =
f(storage,
  cpu,
  memory,
  workload,
  locality,
  writes,
  reads,
  indexes)

Muito familiar, não?

🧟 Capítulo XXIII — O fantasma chamado Garbage Collection

Lembremos:

Clojure/JVM.

Peers.

Caches.

Objetos.

RAM.

E então surge das profundezas:

O COBOLzeiro:

“EU SABIA!”

😂

Mais RAM nem sempre significa simplesmente:

MAIS RAM = MAIS RÁPIDO

Heap, cache, allocation patterns e garbage collection precisam ser observados.

O submarino continua sujeito às leis da JVM.

🏦 Capítulo XXIV — Então Nubank colocou tudo numa database monstruosa?

Não.

E isso é crucial.

O sucesso do Datomic dentro do Nubank não deve ser imaginado assim:

         ONE DATOMIC

█████████████████████████████
TODOS OS CLIENTES
TODOS OS PRODUTOS
TODAS AS TRANSAÇÕES
█████████████████████████████

A arquitetura evoluiu em torno de muitos serviços e databases.

Ou seja, escala pode ser obtida também decompondo:

PLATFORM
   │
   ├── SERVICE A → DATABASE A
   │
   ├── SERVICE B → DATABASE B
   │
   ├── SERVICE C → DATABASE C
   │
   └── SERVICE D → DATABASE D

Agora temos outro tipo de escalabilidade.

Em vez de perguntar:

“Até onde uma única database consegue crescer?”

perguntamos:

“Como particionamos o domínio?”

🔬 Capítulo XXV — O experimento que virou banco gigantesco

Aqui está o aspecto extraordinário.

Quando Nubank escolheu Datomic, não colocou imediatamente cem milhões de clientes sobre ele.

O processo foi aproximadamente:

STARTUP
   │
   ▼
milhares
   │
   ▼
centenas de milhares
   │
   ▼
milhões
   │
   ▼
dezenas de milhões
   │
   ▼
100+ milhões

A arquitetura amadureceu junto com a instituição.

Esse é um experimento completamente diferente de:

BANCO TRADICIONAL

SEXTA 23:59
DESLIGAR DB2

SEGUNDA 06:00
LIGAR DATOMIC

BOA SORTE.

😂

🏭 Capítulo XXVI — Quem mais usa?

E aqui encontramos uma peculiaridade.

Datomic possui outros clientes públicos e o mantenedor fala em centenas de organizações, mas ele jamais alcançou a ubiquidade de:

Oracle
Db2
PostgreSQL
SQL Server
MongoDB

Seu ecossistema continua relativamente especializado.

Isso explica por que alguém pode trabalhar décadas com bancos de dados e praticamente nunca encontrá-lo.

Seu grafo tecnológico está muito mais próximo de:

CLOJURE
   │
   ▼
FUNCTIONAL PROGRAMMING
   │
   ▼
RICH HICKEY
   │
   ▼
COGNITECT
   │
   ▼
DATOMIC

que do universo:

COBOL
 │
CICS
 │
DB2
 │
IMS

Os continentes existem no mesmo planeta.

Mas poucas rotas marítimas os ligavam.

💜 Capítulo XXVII — O cliente compra o construtor do submarino

Agora vem um dos melhores Easter eggs da história.

Datomic era produzido pela Cognitect.

Nubank tornou-se enorme usuário de Clojure e Datomic.

Então, em 23 de julho de 2020, Nubank anunciou a aquisição da Cognitect.

Nubank — aquisição da Cognitect

A sequência fica:

COGNITECT
    │
    ├── CLOJURE
    │
    └── DATOMIC
          │
          ▼
       NUBANK
          │
          ▼
       USA MUITO
          │
          ▼
       ESCALA
          │
          ▼
2020 ─ NUBANK COMPRA COGNITECT

É como se o passageiro do Nautilus dissesse:

“Gostei do submarino.”

E comprasse o estaleiro.

⚠️ Capítulo XXVIII — Mas quem declarou que isso era seguro para finanças?

Ninguém em Brasília publicou:

RESOLUÇÃO Nº 42

Art. 1º Datomic está aprovado.

Art. 2º Clojure está liberado.

Art. 3º Pode ir tranquilo.

😂

Reguladores normalmente não homologam linguagens e bancos de dados dessa maneira.

A responsabilidade continua com a instituição.

A pergunta regulatória é muito mais:

Você controla o risco?

Você protege os dados?

Você garante continuidade?

Você possui governança?

Você testa recuperação?

Você monitora?

Você audita?

Você consegue provar integridade?

Tecnologia é uma parte.

Arquitetura e controles são outra.

🚨 Capítulo XXIX — ACID não significa “banco seguro”

Essa distinção merece uma placa no submarino.

ACID
 ≠
HA
 ≠
DR
 ≠
CYBERSECURITY
 ≠
CORRECTNESS
 ≠
CAPACITY
 ≠
RECONCILIATION

Um database pode funcionar perfeitamente enquanto sua aplicação executa uma regra errada.

AWS       OK
DATOMIC   OK
NETWORK   OK
CPU       OK
MEMORY    OK

BUSINESS RULE
       ↓
      BUG

Parabéns.

Você possui uma infraestrutura extremamente confiável executando o cálculo errado.

Em altíssima velocidade.

💵 Capítulo XXX — Dinheiro precisa fechar

Aqui desaparecem modismos.

Não importa se usamos:

COBOL
CLOJURE
JAVA
RUST

nem:

VSAM
IMS
ADABAS
DB2
DATOMIC

Em algum momento alguém precisa provar:

SALDO INICIAL
+
CRÉDITOS
-
DÉBITOS
=
SALDO FINAL

Σ DÉBITOS
=
Σ CRÉDITOS

E reconciliar:

LEDGER
   ↕
PIX
   ↕
CARTÕES
   ↕
LIQUIDAÇÃO
   ↕
CONTABILIDADE

A tecnologia pode mudar radicalmente.

A contabilidade permanece brutalmente conservadora.

E ainda bem.

🦖 Capítulo XXXI — O dinossauro faz as perguntas certas

Quando um veterano pergunta:

“Quem mais usa?”

isso não é necessariamente resistência à inovação.

É análise de risco.

Quando pergunta:

“Quem fornece suporte?”

é análise de risco.

Quando pergunta:

“Como recupera?”

é análise de risco.

Quando pergunta:

“Qual é o limite?”

é análise de risco.

Quando pergunta:

“Quem atende às 03:47?”

é experiência adquirida através de trauma operacional.

Produtos maduros carregam milhares de funcionalidades aparentemente burocráticas porque algum cliente, em algum domingo, descobriu que precisava delas.

🧭 Capítulo XXXII — O roteiro para um COBOLzeiro aprender Datomic

Não comece por Clojure.

Eu seguiria esta rota:

ETAPA 1
DATOM
E A V T

Entenda o fato.

Depois:

ETAPA 2
ENTITY
ATTRIBUTE
VALUE

Depois:

ETAPA 3
ASSERT
RETRACT

Depois:

ETAPA 4
TIME
HISTORY
AS-OF

Depois:

ETAPA 5
EAVT
AEVT
AVET
VAET

Depois:

ETAPA 6
TRANSACTOR
PEER
STORAGE

Depois:

ETAPA 7
CACHE
MEMORY INDEX
BACKGROUND INDEXING

Depois:

ETAPA 8
DATALOG

E só então:

ETAPA 9

CLOJURE

Porque aí os parênteses terão um motivo para existir.

🐋 Capítulo XXXIII — As dez perguntas universais

Pegue qualquer banco de dados.

Faça sempre estas perguntas:

1. O que representa um dado?

2. Como identifico uma entidade?

3. Como encontro o dado?

4. Como relaciono informações?

5. Como altero estado?

6. Como indexo?

7. Como transaciono?

8. Como recupero?

9. Como escalo?

10. O que acontece quando tudo dá errado?

Aplique a:

VSAM
IMS
ADABAS
DB2
DATOMIC

As respostas mudam.

As perguntas permanecem.

Isso é arquitetura.

🌊 Epílogo — O Nautilus chega ao século XXI

Depois de vinte mil datoms submarinos, nosso COBOLzeiro finalmente encontra o capitão Nemo na sala de máquinas.

— Admito que é interessante.

Nemo sorri.

— Datomic?

— Sim.

— Imutabilidade?

— Interessante.

— Datalog?

— Sobreviverei.

— Clojure?

O COBOLzeiro fica em silêncio.

— Ainda não abuse da sorte.

😂

Ele observa pela janela.

Do lado de fora passam:

EAVT
AEVT
AVET
VAET

como enormes criaturas marinhas.

No painel:

CPU       63%
MEMORY    71%
CACHE HIT 96%
INDEXING  OK
STORAGE   GROWING

O programador sorri.

Porque finalmente reconheceu alguma coisa.

Capacity planning.

Mudamos:

CONTROL INTERVAL

por:

DATOM

Mudamos:

BUFFER POOL

por outras camadas de:

CACHE

Mudamos:

SQL

por:

DATALOG

Mudamos:

DBMS SERVER

por uma arquitetura de:

TRANSACTOR
+
PEERS
+
STORAGE

Mudamos:

UPDATE

por uma filosofia de:

ASSERT
+
RETRACT
+
HISTORY

Mas não conseguimos eliminar:

CPU
MEMÓRIA
STORAGE
I/O
LATÊNCIA
CONTENÇÃO
INDEXAÇÃO
RECOVERY
CAPACITY
AUDITORIA
RISCO

Porque Rich Hickey pode desafiar quarenta anos de design de bancos de dados.

Pode transformar database em valor.

Pode transformar alterações em fatos.

Pode tornar o tempo uma dimensão natural.

Pode separar query, transação e armazenamento.

Pode até convencer um banco brasileiro recém-nascido a apostar numa tecnologia de aproximadamente dois anos e vê-la crescer junto com uma instituição gigantesca.

Mas existe uma força contra a qual nem Clojure consegue argumentar:

a física.

E talvez seja essa a conclusão mais bonita desta viagem.

Datomic não é interessante porque provou que Db2, IMS, Adabas ou VSAM estavam errados.

É interessante porque alguém teve coragem de perguntar se algumas decisões que considerávamos inevitáveis eram realmente inevitáveis.

Em 2012, aquilo parecia quase uma máquina de Júlio Verne.

Em 2014, escolher aquilo para ajudar a construir um banco parecia uma expedição ao fundo do oceano.

Em 2020, o passageiro comprou o estaleiro: o Nubank adquiriu a Cognitect.

E hoje podemos olhar para a experiência acumulada e descobrir algo ainda mais fascinante:

PASSADO

VSAM
IMS
ADABAS
DB2

        ↓

PRESENTE

DATOMIC
CLOJURE
CLOUD

        ↓

FUTURO

?????????

Não precisamos declarar vencedor.

O verdadeiro aprendizado está em entender por que cada geração tomou suas decisões.

Porque daqui a vinte anos algum jovem provavelmente entrará no CPD — ou seja lá como aquilo se chamar — olhará para Datomic, Kubernetes e AWS e dirá:

“Vocês realmente faziam banco desse jeito?”

O velho COBOLzeiro tomará um gole de café.

Olhará para o Nautilus atracado ao lado de um IBM Z.

E responderá:

“Meu jovem, sente-se. Essa história começou muito antes de você imaginar. Primeiro preciso lhe explicar o que era um KSDS.”

E assim começará outra viagem.

Vinte mil datoms abaixo do SELECT. ☕🌊🦖

Translate

terça-feira, 23 de julho de 2024