 |
| Bellacosa Mainframe e o sistema de menssegeria no ibm mainframe. |
☕ Um Café no Bellacosa Mainframe
🪽 HERMES E AS MENSAGENS QUE NÃO PODIAM SE PERDER
IBM MQ, COBOL, CICS, filas, tópicos, Kafka, eventos, persistência, commit, rollback, retry, DLQ, idempotência, observabilidade — e o dia em que Hermes descobriu que entregar uma mensagem aos deuses era muito mais complicado do que simplesmente correr pelo Olimpo.
🎬 PRÓLOGO — O jovem programador e o mensageiro dos deuses
Imagine nosso jovem programador COBOL chegando para trabalhar.
08:07.
Café na mão.
ISPF aberto.
Nenhum ABEND.
Por enquanto.
Seu programa recebe uma transação, atualiza algumas informações no Db2 e precisa avisar outro sistema de que determinada operação aconteceu.
Ele pensa:
— Fácil. Eu chamo o outro programa.
Uma voz surge atrás dele:
— E se ele estiver fora do ar?
O jovem vira a cadeira.
Ali está um sujeito usando sandálias aladas, segurando um caduceu e olhando para o terminal 3270 como se aquilo fosse perfeitamente normal.
— Quem é você?
— Hermes.
Na mitologia grega, Hermes era o mensageiro dos deuses. Circulava entre diferentes mundos levando informações, ordens e notícias.
Em nossa história, portanto, ele conseguiu um emprego novo:
Arquiteto de Integração do Olimpo.
Hermes aponta para a tela.
— Padawan, você está cometendo o primeiro pecado da integração distribuída.
— Qual?
— Acreditar que todo mundo estará disponível quando você precisar.
E assim começa nossa viagem pela mensageria e integração assíncrona no mainframe.
🏛️ CAPÍTULO 1 — O OLIMPO NÃO É UMA ILHA
Durante muito tempo, quem começa a estudar mainframe pode desenvolver uma visão semelhante a esta:
COBOL
│
├── JCL
├── CICS
├── Db2
├── VSAM
└── IMS
Parece um ecossistema fechado.
Mas o mainframe moderno está conectado a praticamente tudo:
MAINFRAME
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Cloud Mobile Web
│ │ │
├───────────────┼───────────────┤
▼ ▼ ▼
APIs Kafka Analytics
│ │
▼ ▼
Microservices Data Platforms
Bancos, seguradoras, empresas aéreas, varejistas, indústrias e governos possuem aplicações construídas em tecnologias e épocas completamente diferentes.
Um programa COBOL pode precisar conversar com:
Java.
Python.
SAP.
Linux.
Windows.
Cloud.
Aplicações móveis.
Microsserviços.
Sistemas parceiros.
Plataformas analíticas.
Hermes sorri.
— Finalmente um trabalho digno de um mensageiro dos deuses.
Mas surge uma questão:
Como fazemos tantos mundos diferentes conversarem de maneira confiável?
Uma das respostas é mensageria.
⚡ CAPÍTULO 2 — ZEUS QUER UMA RESPOSTA AGORA
Antes de entender integração assíncrona, precisamos entender integração síncrona.
Imagine:
PROGRAMA A
│
│ REQUEST
▼
PROGRAMA B
│
│ PROCESSAMENTO
▼
RESPONSE
│
▼
PROGRAMA A
A envia uma solicitação.
A espera.
B processa.
B responde.
A continua.
Isso é perfeitamente adequado para inúmeras situações.
Quando você consulta o saldo bancário, por exemplo, normalmente quer a resposta naquele momento.
Zeus pergunta:
— Quanto tenho na conta?
Você dificilmente responderia:
— Senhor dos trovões, sua solicitação foi aceita. Talvez eu responda amanhã.
⚡
Talvez seja seu último dia no Olimpo.
Portanto, integração síncrona não é ruim.
O problema aparece quando fazemos tudo dessa maneira.
⏳ CAPÍTULO 3 — E SE APOLO ESTIVER FORA DO AR?
Considere:
CICS
│
└────────► SISTEMA B
│
X
OFFLINE
Agora temos perguntas interessantes.
Quanto tempo o CICS deve esperar?
Cinco segundos?
Trinta?
Um minuto?
O que acontece com a transação?
Tentamos novamente?
Quantas vezes?
O usuário fica esperando?
Fazemos rollback?
É aí que Hermes coloca sobre a mesa uma pequena caixa.
— O que é isso?
— Uma fila.
O programador olha desconfiado.
Hermes escreve uma mensagem:
PEDIDO 4711
e coloca dentro da caixa.
— Agora posso ir embora.
— Mas ninguém recebeu!
— Ainda.
Essa palavra muda tudo.
📬 CAPÍTULO 4 — A CAIXA POSTAL DO OLIMPO
A arquitetura agora é:
PRODUTOR
│
│ mensagem
▼
┌───────────────┐
│ QUEUE │
│ │
│ MSG 4711 │
└───────┬───────┘
│
▼
CONSUMIDOR
O produtor não precisa necessariamente esperar que o consumidor processe naquele instante.
Ele entrega a mensagem à infraestrutura de mensageria.
Esse conceito é fundamental:
DESACOPLAMENTO TEMPORAL
Produtor e consumidor não precisam necessariamente estar disponíveis simultaneamente.
Imagine um sistema CICS produzindo mensagens durante uma indisponibilidade temporária do consumidor.
CICS
│
├── MSG 1001 ──► QUEUE
├── MSG 1002 ──► QUEUE
├── MSG 1003 ──► QUEUE
└── MSG 1004 ──► QUEUE
CONSUMIDOR
OFFLINE
Posteriormente:
CONSUMIDOR ONLINE
QUEUE
│
├── MSG 1001
├── MSG 1002
├── MSG 1003
└── MSG 1004
│
▼
PROCESSAMENTO
Esse princípio é conhecido como store-and-forward.
Hermes comenta:
— Finalmente inventaram algo melhor que minhas pernas.
🟦 CAPÍTULO 5 — HERMES CONHECE IBM MQ
No universo IBM Z, um dos grandes protagonistas dessa história é o IBM MQ.
Para nosso Padawan, vamos começar pelo modelo mais simples:
┌──────────────┐
│ COBOL / CICS │
└──────┬───────┘
│
│ MQPUT
▼
┌─────────────────────┐
│ IBM MQ │
│ │
│ Queue Manager │
│ │ │
│ ▼ │
│ QUEUE │
└─────────┬───────────┘
│
│ MQGET
▼
┌─────────────────────┐
│ CONSUMIDOR │
└─────────────────────┘
Guarde inicialmente duas palavras:
MQPUT coloca uma mensagem.
MQGET obtém uma mensagem.
Claro que IBM MQ é muito maior que isso.
Mas todo Jedi começou segurando um sabre de treinamento.
💳 CAPÍTULO 6 — HERMES COMPRA UM CAFÉ
Hermes desce do Olimpo e compra um café.
R$ 12.
Uma simples compra pode provocar vários processamentos:
COMPRA
│
├── autorização
├── registro financeiro
├── antifraude
├── notificação
├── cashback
├── analytics
└── histórico
Agora imagine executar tudo sincronamente:
COMPRA
│
├──► ANTIFRAUDE
├──► NOTIFICAÇÃO
├──► CASHBACK
├──► ANALYTICS
└──► HISTÓRICO
Analytics ficou indisponível.
Devemos impedir Hermes de tomar café?
Provavelmente não.
Aqui surge uma importante decisão arquitetural:
O que precisa acontecer antes da resposta e o que pode acontecer depois?
Podemos ter:
COMPRA
│
▼
AUTORIZAÇÃO
│
OK
│
┌─────────┴─────────┐
▼ ▼
RESPONDE AO POS EVENTO
│
▼
MENSAGERIA
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Analytics Cashback Notificação
Agora estamos pensando como arquitetos.
Mensageria não é simplesmente colocar informações em uma fila.
É decidir onde podemos remover dependências.
🔖 CAPÍTULO 7 — O PERGAMINHO 4711
Integração assíncrona não significa necessariamente ausência de resposta.
Imagine que Hermes entregue:
REQUEST-ID = 4711
O consumidor processa e posteriormente envia:
CORRELATION-ID = 4711
Assim podemos relacionar:
REQUEST 4711
│
▼
processamento
│
▼
RESPONSE 4711
Isso é correlação.
Imagine milhares de solicitações circulando pelo Olimpo.
Sem identificadores seria caos.
Correlation IDs também são extremamente úteis para observabilidade.
Quando alguém disser:
— Minha transação desapareceu!
você poderá procurar o identificador através das diferentes etapas.
Hermes chama isso de:
rastreamento do pergaminho sagrado.
O pessoal de observabilidade prefere chamar de tracing.
💾 CAPÍTULO 8 — A MENSAGEM NÃO PODE DESAPARECER
Nem toda mensagem possui a mesma importância.
Considere:
CPU = 43%
Talvez perder uma amostra de telemetria seja tolerável.
Agora considere:
TRANSFERENCIA
ORIGEM=123
DESTINO=456
VALOR=50000
A conversa muda.
Mensageria empresarial permite trabalhar com diferentes requisitos de persistência e confiabilidade.
Mas isso envolve trade-offs.
Persistência e garantias adicionais possuem custos.
Portanto a pergunta não é simplesmente:
"Persistente é melhor?"
A pergunta correta é:
"Qual nível de garantia o negócio exige?"
Essa mudança de pergunta é uma característica importante de engenharia.
🔄 CAPÍTULO 9 — HERMES ENTREGA A MESMA CARTA DUAS VEZES
Chegamos a uma das partes mais perigosas.
Uma mensagem diz:
PAGAR R$ 100
TRANSACTION-ID = ABC123
O consumidor processa.
PAGAMENTO OK
Mas alguma falha ocorre no momento errado.
A infraestrutura pode, dependendo do desenho e das garantias adotadas, apresentar a mensagem novamente.
O programa recebe:
PAGAR R$ 100
TRANSACTION-ID = ABC123
e paga novamente.
Agora temos:
R$100 + R$100 = R$200
E alguém recebe um telefonema às:
03:17.
Easter egg encontrado. ☕
A palavra mágica é:
IDEMPOTÊNCIA
O consumidor deve conseguir reconhecer que:
ABC123
já produziu seu efeito de negócio.
Por exemplo:
ABC123 JÁ PROCESSADA?
SIM ──► não repetir efeito
NÃO ──► processar
Esse assunto é fundamental quando ouvimos a expressão exactly-once.
Sempre pergunte:
Exactly-once onde?
No broker?
No transporte?
No consumidor?
No banco?
No efeito financeiro final?
Sistemas distribuídos adoram transformar frases simples em problemas profundamente interessantes.
☠️ CAPÍTULO 10 — MEDUSA ENTROU NA FILA
Agora temos:
MSG 001 → OK
MSG 002 → OK
MSG 003 → ERRO
MSG 004
MSG 005
Tentamos MSG 003 novamente.
Erro.
Novamente.
Erro.
Novamente.
Erro.
Ela petrifica qualquer consumidor que tente processá-la.
Hermes olha para a fila.
— Medusa.
Na engenharia chamamos algo semelhante de poison message.
Precisamos impedir ciclos infinitos:
GET
│
▼
ERROR
│
▼
ROLLBACK
│
▼
GET
│
▼
ERROR
Uma arquitetura madura estabelece políticas de retry e tratamento de mensagens problemáticas.
Depois de determinado tratamento ou número de tentativas, a mensagem pode ser direcionada para análise.
Entram em cena mecanismos associados a Dead-Letter Queues.
QUEUE
│
▼
PROCESSAMENTO
│
├──────────────► OK
│
▼
ERROR
│
▼
RETRY
│
▼
continua falhando
│
▼
DLQ
Mas atenção:
DLQ não é cemitério.
Uma DLQ que ninguém monitora é apenas um lugar elegante para esconder incidentes.
⏱️ CAPÍTULO 11 — NÃO ATAQUE UM SISTEMA QUE JÁ ESTÁ CAÍDO
Retry também pode causar desastre.
Imagine 100 mil mensagens falhando.
Todas tentam novamente imediatamente.
100.000
│
▼
RETRY
│
▼
SERVIÇO DOENTE
O serviço tenta recuperar-se enquanto recebe uma avalanche.
Podemos utilizar estratégias de backoff:
tentativa 1
│
▼
espera
│
tentativa 2
│
▼
espera maior
│
tentativa 3
Também pode haver jitter, introduzindo variação para evitar que milhares de clientes façam retry exatamente no mesmo instante.
Hermes resume:
— Se a porta do templo está quebrada, mandar dez mil pessoas baterem nela simultaneamente dificilmente vai consertá-la.
🔐 CAPÍTULO 12 — HADES DESCOBRE COMMIT E ROLLBACK
Agora entramos em território profundamente mainframe.
Imagine:
CICS
│
├── UPDATE Db2
│
└── MQPUT
Queremos consistência.
Uma situação perigosa seria:
Db2 = COMMIT
MQ = ROLLBACK
Ou o inverso:
Db2 = ROLLBACK
MQ = COMMIT
Dependendo da arquitetura e dos recursos envolvidos, CICS, Db2 e MQ podem participar de unidades de trabalho coordenadas.
Conceitualmente:
┌─────────────────────────────┐
│ UNIT OF WORK │
│ │
│ UPDATE DB2 │
│ MQPUT │
│ │
│ COMMIT / ROLLBACK │
└─────────────────────────────┘
E aqui existe uma deliciosa curiosidade histórica.
Muita gente olha para arquiteturas modernas distribuídas como se problemas de consistência tivessem sido descobertos ontem.
Mainframeiros olham para aquilo segurando uma xícara de café e pensam:
— Interessante. Estamos discutindo commit, rollback, recovery e integridade há algumas décadas.
📢 CAPÍTULO 13 — HERMES DESCOBRE O PUB/SUB
Fila e tópico não são a mesma coisa.
No modelo clássico de queue:
PRODUTOR
│
▼
QUEUE
│
▼
CONSUMIDOR
Agora imagine um acontecimento:
PAYMENT.APPROVED
Muitos sistemas estão interessados.
PAYMENT.APPROVED
│
▼
TOPIC
│
┌───────────┼───────────┐
▼ ▼ ▼
Marketing Analytics Notificação
Entramos em Publish/Subscribe.
O produtor publica algo.
Interessados assinam.
Isso permite diminuir determinado tipo de acoplamento.
Em vez de:
A conhece B
A conhece C
A conhece D
A conhece E
podemos ter:
A
│
▼
"PAYMENT.APPROVED"
│
▼
BROKER
A informa que algo aconteceu.
Os interessados decidem o que fazer.
📜 CAPÍTULO 14 — COMANDO NÃO É EVENTO
Hermes recebe dois pergaminhos.
Primeiro:
GENERATE-INVOICE
Segundo:
INVOICE-GENERATED
Parecem semelhantes.
Semanticamente são diferentes.
O primeiro é uma intenção ou comando:
Faça alguma coisa.
O segundo descreve um fato:
Alguma coisa aconteceu.
Compare:
COMMAND
└──► SHIP-ORDER
com:
EVENT
└──► ORDER-SHIPPED
Essa distinção é extremamente importante em arquiteturas orientadas a eventos.
Um evento deve representar algo significativo que ocorreu no domínio.
🐘 CAPÍTULO 15 — ZEUS PERGUNTA: "E KAFKA?"
É inevitável.
Alguém menciona mensageria.
Cinco minutos depois:
Kafka.
Apache Kafka é uma plataforma de event streaming distribuído.
Mas não devemos resumir a discussão a:
Kafka = MQ novo
ou:
MQ = Kafka velho
É uma simplificação ruim.
Como primeiro mapa mental:
IBM MQ
│
├── queues
├── reliable messaging
├── integração empresarial
├── routing
└── forte tradição transacional
Enquanto Kafka trabalha fortemente com conceitos como:
Kafka
│
├── topics
├── partitions
├── offsets
├── retention
├── replay
└── event streaming
No Kafka, podemos imaginar:
TOPIC
│
├── PARTITION 0
│ ├── EVENT 0
│ ├── EVENT 1
│ └── EVENT 2
│
└── PARTITION 1
├── EVENT 0
└── EVENT 1
Consumidores acompanham posições usando offsets.
Dependendo da retenção e arquitetura, eventos podem ser relidos.
Isso abre possibilidades interessantes para:
analytics,
event streaming,
integração,
reprocessamento,
data platforms,
event-driven architectures.
🤝 CAPÍTULO 16 — MQ E KAFKA NÃO PRECISAM DUELAR
Hermes coloca IBM MQ de um lado.
Kafka do outro.
Zeus prepara um raio.
— Que vença o melhor!
Hermes responde:
— Não funciona assim.
Podemos perfeitamente encontrar arquiteturas contendo:
IBM Z
│
COBOL / CICS
Db2 / IMS
│
▼
IBM MQ
│
┌────────┴────────┐
▼ ▼
Sistemas Integração
corporativos │
▼
Kafka
│
┌────────────┼────────────┐
▼ ▼ ▼
Cloud Analytics Data
Não precisamos transformar tecnologia em religião.
A pergunta profissional é:
Qual problema estou tentando resolver?
📚 CAPÍTULO 17 — O COPYBOOK ENCONTRA O JSON
Mensageria precisa de contratos.
Imagine:
{
"customer": 123,
"amount": 500
}
Alguém altera para:
{
"customerId": 123,
"amount": 500,
"currency": "BRL"
}
Consumidores antigos podem ter problemas.
O programador COBOL deveria imediatamente reconhecer o conceito.
Veja:
01 CUSTOMER-RECORD.
05 CUSTOMER-ID PIC 9(10).
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-STATUS PIC X.
Copybooks também representam contratos estruturais entre programas e dados.
No ecossistema distribuído encontramos mecanismos como:
JSON Schema,
Avro,
Protocol Buffers.
Todos enfrentam questões familiares:
estrutura,
tipos,
campos,
versões,
compatibilidade,
evolução.
Portanto, quando alguém disser que contratos de dados são uma inovação moderna, não discuta.
Tome um café.
Mostre um copybook de 1987.
Continue trabalhando.
📈 CAPÍTULO 18 — A FILA COMEÇA A ENGORDAR
Agora Hermes encontra:
PRODUTOR
10.000 mensagens/s
CONSUMIDOR
6.000 mensagens/s
Temos:
10.000 - 6.000
=
4.000 mensagens/s
acumulando.
Em uma hora:
4.000 × 3.600
=
14.400.000 mensagens
Nenhum programa necessariamente sofreu ABEND.
Nenhum servidor necessariamente caiu.
Mesmo assim temos um incidente crescendo.
Esse fenômeno nos leva ao conceito de backpressure.
PRODUÇÃO
10.000/s
│
▼
████████████████████████████
QUEUE
│
▼
6.000/s
CONSUMIDOR
Agora precisamos pensar em capacidade.
Podemos aumentar consumidores?
Existe processamento paralelo?
Precisamos preservar ordenação?
Qual o tamanho das mensagens?
Quanto podemos acumular?
Qual é o SLA?
Qual é o limite operacional?
🔭 CAPÍTULO 19 — HERMES INSTALA OBSERVABILIDADE NO OLIMPO
Mensageria sem observabilidade pode virar uma caixa-preta.
Precisamos conhecer coisas como:
queue depth
message age
throughput
consumer rate
processing latency
error rate
retry count
DLQ depth
end-to-end latency
Existe uma armadilha particularmente interessante.
Uma fila contendo:
100.000 mensagens
pode estar saudável se processar centenas de milhares rapidamente.
Enquanto outra contendo:
37 mensagens
pode estar em situação crítica se a mensagem mais antiga estiver esperando quatro horas.
Portanto:
QUEUE DEPTH NÃO CONTA TODA A HISTÓRIA.
Precisamos observar também message age.
Pergunte:
Qual é a idade da mensagem mais antiga?
Essa simples pergunta pode revelar problemas invisíveis.
🔢 CAPÍTULO 20 — A ORDEM DOS PERGAMINHOS
Considere:
1 CUSTOMER.CREATED
2 CUSTOMER.UPDATED
3 CUSTOMER.DELETED
Esperamos:
1 → 2 → 3
Mas sistemas distribuídos e processamento paralelo exigem cuidado com ordenação.
Imagine:
1 → 3 → 2
Agora tentamos atualizar algo depois de excluí-lo.
Surge outra grande decisão arquitetural:
Onde realmente precisamos preservar ordem?
Ordenação global pode limitar paralelismo e throughput.
Por isso tecnologias modernas trabalham com conceitos como:
partition,
key,
grouping,
sequence.
Às vezes precisamos preservar ordem apenas para determinado cliente:
CUSTOMER 123
1 → 2 → 3
enquanto outro cliente pode ser processado independentemente:
CUSTOMER 999
1 → 2 → 3
Isso permite paralelismo sem abandonar a ordem relevante para o negócio.
🕸️ CAPÍTULO 21 — O ESPAGUETE ASSÍNCRONO
Hermes abre um diagrama antigo.
A → Q1 → B
│
└── Q2 → C
│
Q7
│
▼
D → Q13
│
▼
E → Q29
│
▼
???
— Quem criou Q29?
Silêncio.
— Quem consome?
Silêncio.
— Podemos remover?
Um velho programador COBOL levanta lentamente a cabeça:
— Está aí desde 2004.
Hermes:
— E?
— Melhor não mexer.
Bem-vindo à arqueologia corporativa.
Mensageria também pode produzir spaghetti architecture.
Por isso precisamos de:
documentação,
ownership,
catálogo de interfaces,
contratos,
versionamento,
observabilidade,
governança,
naming standards,
políticas de retenção,
procedimentos de recuperação.
Tecnologia excelente sem governança continua capaz de produzir caos excelente.
🌉 CAPÍTULO 22 — MODERNIZAR NÃO SIGNIFICA DEMOLIR O TEMPLO
Existe uma visão simplista:
MODERNIZAÇÃO
=
tirar COBOL
Não.
Modernização pode significar:
COBOL
│
negócio crítico
│
┌───────┴────────┐
▼ ▼
API MQ
│ │
▼ ▼
síncrono assíncrono
│ │
└────────┬───────┘
▼
ECOSSISTEMA
│
┌────────┼────────┐
▼ ▼ ▼
Cloud Kafka Mobile
O COBOL pode continuar executando perfeitamente a lógica crítica.
Mudamos a maneira como essa lógica participa do ecossistema.
Isso também é modernização.
Talvez o problema nunca tenha sido o programa COBOL.
Talvez fosse o acoplamento em torno dele.
🧭 CAPÍTULO 23 — PASSO A PASSO DO PADAWAN
Se você está começando agora, não tente aprender IBM MQ inteiro em um fim de semana.
Hermes recomenda uma trilha.
Passo 1 — Entenda produtor e consumidor.
Quem cria a mensagem?
Quem processa?
Passo 2 — Entenda queue.
Aprenda o modelo básico:
PRODUCER → QUEUE → CONSUMER
Passo 3 — Estude PUT e GET.
No universo MQ:
MQPUT
MQGET
Passo 4 — Estude persistência.
O que acontece se alguma coisa cair?
Passo 5 — Estude unidade de trabalho.
COMMIT
ROLLBACK
Passo 6 — Provoque erros mentalmente.
Pergunte sempre:
E SE?
E se o consumidor cair?
E se a rede cair?
E se receber duas vezes?
E se a mensagem estiver inválida?
E se 10 milhões chegarem?
E se ficarem seis horas esperando?
Passo 7 — Estude correlação.
Aprenda a seguir uma transação ponta a ponta.
Passo 8 — Estude retry e DLQ.
Falha não é exceção em sistemas distribuídos.
Falha faz parte do projeto.
Passo 9 — Estude idempotência.
Pergunte:
Posso executar isso duas vezes sem cobrar duas vezes o cliente?
Passo 10 — Aprenda Pub/Sub.
Depois diferencie:
COMMAND
de:
EVENT
Passo 11 — Estude Kafka.
Somente então compare modelos.
Passo 12 — Aprenda observabilidade.
Não basta entregar mensagens.
Precisamos provar que foram entregues e saber o que aconteceu quando não foram.
🧠 CAPÍTULO 24 — AS PERGUNTAS QUE TRANSFORMAM O PROGRAMADOR EM ENGENHEIRO
Quando receber uma integração para desenvolver, não pergunte apenas:
Qual COPYBOOK?
Pergunte:
Precisa ser síncrona?
Pode ser assíncrona?
Podemos receber duplicatas?
Precisamos preservar ordem?
Qual é o SLA?
Quanto tempo podemos acumular?
Qual é a unidade de trabalho?
Quem faz commit?
O que acontece no rollback?
Existe retry?
Qual política de backoff?
Existe DLQ?
Quem monitora a DLQ?
Existe correlation ID?
Como fazemos tracing?
O contrato possui versão?
Quem é o owner?
Como recuperamos mensagens?
Como sabemos que a recuperação terminou?
Essas perguntas valem muito mais do que simplesmente decorar uma API.
🏛️ EPÍLOGO — HERMES ENTREGA A ÚLTIMA MENSAGEM
Anoitece no Olimpo.
Nosso Padawan fecha o ISPF.
Hermes guarda seu caduceu.
O jovem programador finalmente percebe que passou o dia inteiro estudando filas, tópicos, mensagens, eventos, MQ, Kafka, commit, rollback, idempotência, DLQ, retry e observabilidade.
Mas aprendeu algo maior.
Mensageria não é sobre transportar bytes.
É sobre administrar dependências entre sistemas que inevitavelmente falharão em momentos diferentes.
Uma arquitetura síncrona pergunta:
"Você está disponível agora?"
Uma arquitetura assíncrona pode dizer:
"Tenho algo importante para você. Pegue quando puder, dentro das regras que estabelecemos."
Essa diferença permite construir sistemas extraordinariamente resilientes.
Hermes coloca sobre a mesa seu último pergaminho:
MESSAGE-ID: HERMES-0001
PERSISTENCE: YES
CORRELATION-ID: BELLACOSA
STATUS: DELIVERED
O Padawan pergunta:
— Então finalmente entendi IBM MQ?
Hermes ri.
— Não.
— Não?!
— Você entendeu algo mais importante.
— O quê?
Hermes aponta para o mainframe.
— Por que ele existe.
Porque sistemas críticos não vivem em um universo perfeito.
Redes caem.
Serviços param.
Consumidores atrasam.
Mensagens chegam duplicadas.
Dados mudam.
Filas crescem.
Aplicações sofrem rollback.
Máquinas reiniciam.
Deploys dão errado.
E eventualmente alguém faz alguma coisa inexplicável numa sexta-feira à tarde.
Engenharia de sistemas críticos não consiste em acreditar que nada disso acontecerá.
Consiste em construir sistemas preparados para continuar corretos quando acontecer.
Talvez seja justamente por isso que conceitos de mensageria combinam tão bem com o mundo mainframe.
O mainframe nunca foi construído partindo da pergunta:
"Como fazemos uma demonstração bonita?"
Ele nasceu em um mundo que perguntava:
"O que acontece se isso der errado?"
Essa pergunta atravessou gerações.
Do batch ao CICS.
Do VSAM ao Db2.
Do terminal 3270 às APIs.
Do MQ ao Kafka.
Do datacenter à cloud.
As tecnologias mudaram.
A responsabilidade permaneceu.
Hermes calça novamente suas sandálias aladas.
Antes de partir, olha uma última vez para nosso jovem programador COBOL:
— Amanhã estudaremos uma coisa chamada event-driven architecture.
O Padawan sorri:
— Parece moderno.
Hermes também sorri.
— É. Mas traga café.
— Por quê?
— Porque os humanos inventaram um nome novo para algo que vai nos fazer discutir commit, rollback, entrega, ordenação e recuperação outra vez.
E desaparece pelos corredores do Olimpo.
No terminal permanece apenas uma mensagem:
***************************************
* HERMES MESSAGE DELIVERY SYSTEM *
***************************************
MESSAGE ......... BELLACOSA-0317
STATUS .......... DELIVERED
QUEUE DEPTH ..... 00000000
OLDEST MSG AGE .. 00:00:00
DLQ DEPTH ....... 00000000
ALL SYSTEMS NORMAL.
***************************************
* NEVER TRUST "ALL SYSTEMS NORMAL". *
***************************************
Nosso Padawan olha para o relógio.
03:17.
☕
Em algum lugar do datacenter, uma fila começa lentamente a crescer.
QUEUE DEPTH: 00000001
Hermes já havia ido embora.
Mas a aula seguinte acabara de começar.
☕ Moral do Bellacosa Mainframe
Mensageria não é colocar uma mensagem numa fila.
É saber:
quem envia, quem recebe, quando recebe, quantas vezes pode receber, em qual ordem, durante quanto tempo podemos esperar, o que acontece se ninguém receber, como recuperamos, como impedimos duplicidade, como observamos o caminho e como mantemos o negócio correto quando alguma peça inevitavelmente falhar.
Quando o programador COBOL começa a fazer essas perguntas, deixa de enxergar apenas programas.
Passa a enxergar sistemas.
Quando começa a enxergar sistemas, deixa de tratar MQ como apenas mais uma API.
Passa a compreender arquitetura.
E quando entende arquitetura, finalmente percebe por que Hermes, mensageiro dos deuses, teria se sentido perfeitamente em casa diante de um IBM Z:
uma mensagem só cumpriu sua missão quando chegou ao destino certo, no contexto certo, com integridade — e existe evidência suficiente para provar isso.
☕ Bem-vindo ao Bellacosa Mainframe. Onde até os deuses precisam respeitar COMMIT e ROLLBACK.
