quinta-feira, 9 de fevereiro de 2012

😈 CAP Theorem explicado para quem já confiou em commit em duas fases

00:00 — Introdução: quando a teoria virou dor real

Se você é mainframer e já confiou em Two-Phase Commit, já viveu o CAP Theorem antes dele ter nome.
A diferença é que, no mainframe, chamávamos isso de:

“Ou o dado está certo, ou o sistema fica em pé. Os dois ao mesmo tempo… depende.”

O Teorema CAP nasceu no mundo distribuído moderno, mas suas raízes estão lá atrás, nos tempos de IMS, CICS, DB2, sysplex e coordenação distribuída feita no braço.

1️⃣ O que é CAP (sem marketing)

CAP diz que, em um sistema distribuído, quando ocorre uma falha de rede, você só pode garantir duas das três propriedades:

C – Consistency (Consistência)
Todos veem o mesmo dado ao mesmo tempo.
A – Availability (Disponibilidade)
O sistema sempre responde.
P – Partition Tolerance (Tolerância a partições)
O sistema continua funcionando mesmo com falhas de rede.

⚠️ Spoiler mainframer:
P não é opcional. Se existe rede, vai haver partição.

2️⃣ A tradução CAP → dialeto mainframe 🧠

CAP	Mainframe raiz entende como
Consistency	Commit garantido, dado íntegro
Availability	Região em pé, SLA preservado
Partition	Link caiu, LPAR isolada, XCF brigando

👉 CAP não é escolha ideológica.
É decisão de sobrevivência.

3️⃣ Two-Phase Commit: o trauma fundador 😵

Fase 1 – Prepare

Todos dizem: “posso gravar?”
Locks segurados
Esperança intacta

Fase 2 – Commit

Coordenador manda gravar
Um nó não responde…
Silêncio
Lock eterno
DBA acordado

😈 Easter egg:
Quem já viu in-doubt transaction sabe que CAP não é slide de PowerPoint.

4️⃣ Onde o CAP dói de verdade

🔥 Consistência vs Disponibilidade

Quer dado correto?
→ Pode ficar indisponível.
Quer sistema respondendo?
→ Pode responder com dado antigo.

No mainframe, a escolha histórica foi:

Consistência acima de tudo.

No mundo web:

Disponibilidade acima de tudo.

5️⃣ Por que P não se discute

Em ambiente distribuído:

Switch falha
Roteador reinicia
Zona cai
Cloud provider “pisca”

📌 Curiosidade:
No sysplex, a IBM passou décadas tentando domar P com hardware, coupling facility e engenharia absurda.

Mesmo assim… partição acontece.

6️⃣ Modelos modernos (com cheiro de legado)

CP – Consistent + Partition tolerant

DB2
Sistemas financeiros
Core banking

💬 “Se não gravar certo, melhor não gravar.”

AP – Available + Partition tolerant

Cassandra
DynamoDB
Sistemas de catálogo, feeds, logs

💬 “Mostra algo agora, conserta depois.”

7️⃣ Eventual Consistency: o nome chique do “daqui a pouco acerta”

Mainframer traduz:

“Batch de reconciliação”

Dados podem divergir temporariamente
Em algum momento, convergem
Desde que não falhe tudo 😈

📎 Easter egg:
Você já fez eventual consistency com VSAM + batch noturno e nem percebeu.

8️⃣ Passo a passo para decidir CAP na prática

1️⃣ O dado é financeiro ou regulatório?
→ C é obrigatório

2️⃣ O usuário pode esperar?
→ Talvez A não seja crítica

3️⃣ Se a rede cair, pode parar tudo?
→ Se não, aceite inconsistência temporária

4️⃣ Existe reconciliação posterior?
→ Batch, eventos, compensação

5️⃣ Quem assume o erro?
→ Sistema ou negócio?

9️⃣ Guia de estudo para mainframers inquietos 📚

Conceitos

CAP Theorem
PACELC (CAP com latência)
Eventual Consistency
Sagas (compensação)

Ferramentas e paralelos

XA / 2PC → Transaction Coordinator
Kafka → MQ + replay
Sagas → Rollback manual versão cloud
Observabilidade → SMF espiritual

🔟 Aplicações práticas no mundo híbrido

Integrar DB2 com microservices
Decidir quando expor APIs síncronas
Projetar sistemas resilientes
Evitar 2PC em cloud (sim, evite!)
Atuar como arquiteto de verdade, não só operador

🎯 Mainframer que entende CAP vira arquiteto respeitado.

1️⃣1️⃣ Comentário final (02:17 da manhã)

CAP não é teoria acadêmica.
É a explicação formal da dor que você já sentiu.

Se você já:

Perdeu noite por commit travado
Desconfiou de dado “meio gravado”
Escolheu derrubar tudo para não corromper

Então parabéns.
Você praticou CAP antes de virar hype.

🖤 El Jefe Midnight Lunch conclui:
Cloud é só o mainframe que esqueceu suas lições.