⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

 

Bellacosa Mainframe e os 7 protocolos nas APIs

☕ Um Café no Bellacosa Mainframe

⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

REST, GraphQL, gRPC, WebSockets, Webhooks, SSE, MQTT, mensageria, eventos, idempotência, sistemas distribuídos — e o dia em que Mitsuha descobriu que uma API mal escolhida pode custar muito mais que 80.000 moedas de ouro.

---

🎬 PRÓLOGO — MITSUHA ENCONTROU SETE PORTAIS

Mitsuha Yamano olhou para o quadro.

Havia sete portais desenhados diante dela:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Ao lado estava um jovem programador COBOL.

Ele conhecia algumas coisas.

Sabia que:

MOVE 100 TO WS-QUANTIDADE.

IF WS-SALDO >= WS-VALOR
    PERFORM PROCESSA-PAGAMENTO
END-IF.

Sabia alguma coisa sobre arquivos, JCL e talvez estivesse começando a descobrir CICS, Db2 e VSAM.

Mas aquela sopa de siglas modernas parecia magia.

Mitsuha olhou para ele.

— Qual você escolheria?

— REST.

— Por quê?

— Porque todo mundo usa REST.

Mitsuha suspirou.

Era exatamente assim que se perdia uma fortuna em outro mundo.

Porque a primeira lição desta aventura é:

Tecnologia não deve ser escolhida porque está na moda. Ela deve ser escolhida porque resolve adequadamente um problema.

E REST, GraphQL, gRPC, WebSocket, Webhooks, SSE e MQTT não são simplesmente sete concorrentes tentando conquistar o mesmo reino.

Eles resolvem tipos diferentes de conversa entre sistemas.

Prepare o café.

Nossa dungeon começa aqui.

---

🏰 CAPÍTULO 1 — ANTES DA API EXISTIA A CONVERSA

Antes de falarmos sobre REST, precisamos entender algo muito mais básico.

Computadores precisam conversar.

Imagine dois programas:

PROGRAMA A

     precisa de uma informação

          ↓

PROGRAMA B

Se os dois estão dentro do mesmo processo, a comunicação pode ser relativamente simples.

No COBOL podemos ter:

CALL 'CALCJURO'
    USING WS-VALOR
          WS-TAXA
          WS-RESULTADO.

O programa chama outro programa.

Mas imagine que CALCJURO não está na mesma máquina.

Ele está em outro servidor.

Talvez em outro datacenter.

Talvez em outro país.

Agora temos:

Programa A
    |
    | REDE
    |
    v
Programa B

Acabamos de entrar no mundo dos sistemas distribuídos.

E a rede acrescentou vários monstros à dungeon:

latência
timeout
queda de conexão
mensagem duplicada
mensagem perdida
servidor indisponível
autenticação
autorização
criptografia
ordenação
retry

Quando tudo acontece dentro de um programa COBOL, podemos pensar:

PERFORM A
PERFORM B
PERFORM C

Quando distribuímos isso pela rede, precisamos começar a pensar:

Enviei A.

Será que chegou?

Se chegou, será que processou?

Se processou, por que não respondeu?

Posso enviar novamente?

Se enviar novamente, será executado duas vezes?

Bem-vindo à arquitetura distribuída.

---

🌐 CAPÍTULO 2 — O PRIMEIRO PORTAL CHAMA-SE REST

REST significa:

Representational State Transfer.

O termo ficou conhecido a partir do trabalho acadêmico de Roy Fielding no início dos anos 2000.

Mas cuidado com uma simplificação muito comum:

REST não significa simplesmente “JSON trafegando por HTTP”.

REST é um estilo arquitetural.

Uma das ideias mais importantes é trabalhar com recursos.

Imagine um banco.

Existem:

CLIENTE
CONTA
CARTÃO
PAGAMENTO
EMPRÉSTIMO

Podemos representar esses recursos por endereços:

/customers/12345

/accounts/98765

/cards/45678

E utilizar métodos HTTP.

Por exemplo:

GET /customers/12345

significa aproximadamente:

Quero consultar o cliente 12345.

Enquanto:

POST /payments

poderia significar:

Quero criar um novo pagamento.

Temos métodos conhecidos como:

GET
POST
PUT
PATCH
DELETE

Uma associação didática comum seria:

GET       consultar
POST      criar/processar
PUT       substituir/atualizar
PATCH     alterar parcialmente
DELETE    remover

Mas não transforme isso numa religião. A semântica real da API precisa ser bem projetada.

---

🧙 CAPÍTULO 3 — MITSUHA COLOCA CICS ATRÁS DO PORTAL

Agora nosso COBOLzeiro pergunta:

— Preciso jogar meu COBOL fora para criar APIs?

Mitsuha quase derrubou o café.

Não.

Esse é justamente um dos pontos mais interessantes da modernização de mainframe.

Imagine um programa COBOL executado por CICS contendo uma regra de negócio importantíssima:

Aplicativo Mobile
       |
       | HTTPS / REST
       v
    API Layer
       |
       v
 z/OS Connect
       |
       v
     CICS
       |
       v
     COBOL
       |
   +---+---+
   |       |
  Db2     VSAM

O aplicativo moderno não precisa necessariamente conhecer detalhes internos do COBOL.

Ele pode pedir:

GET /accounts/12345/balance

Uma camada de integração transforma essa requisição em algo compreensível pelo ambiente existente.

O COBOL executa sua lógica.

O resultado volta.

Talvez como:

{
  "account": "12345",
  "balance": 8750.42,
  "currency": "BRL"
}

Observe o detalhe.

O COBOL pode continuar fazendo aquilo que faz bem:

regra de negócio
transação
processamento
acesso aos dados

A API torna essa capacidade acessível ao restante do ecossistema.

Modernização não significa obrigatoriamente:

destruir o sistema antigo.

Às vezes significa:

construir uma porta moderna para um sistema extremamente valioso.

---

🧬 CAPÍTULO 4 — GRAPHQL ENTRA NA LOJA DE MITSUHA

Agora imagine que Mitsuha abriu sua loja.

Na tela inicial ela precisa mostrar:

Nome
Saldo
Últimas compras
Cartões
Limite
Notificações

Com determinadas APIs REST, poderíamos acabar fazendo:

GET /customer/123
GET /customer/123/accounts
GET /customer/123/cards
GET /customer/123/orders
GET /customer/123/notifications

Cinco requisições.

Outra API poderia responder tudo em uma chamada, mas devolver 80 campos quando a tela utiliza apenas 7.

Temos dois problemas clássicos.

Over-fetching

Você pede pouca coisa e recebe uma carroça inteira.

PRECISO:

nome
saldo


RECEBO:

nome
saldo
endereço
telefone
data nascimento
histórico
cartões
preferências
...

Under-fetching

Você recebe tão pouco que precisa continuar perguntando:

cliente?

agora cartões?

agora pedidos?

agora itens?

agora endereço?

GraphQL oferece outra abordagem.

O cliente pode declarar os campos desejados:

query {
  customer(id: 123) {
    name
    accounts {
      balance
    }
  }
}

Isso é poderoso especialmente em interfaces com necessidades de dados complexas.

Mas Mitsuha levanta o dedo:

— Não existe magia grátis.

GraphQL também traz desafios:

schemas
resolvers
cache
autorização
complexidade das consultas
observabilidade
N+1 queries
limitação de profundidade
controle de custo

Uma consulta aparentemente inocente pode gerar enorme trabalho internamente se a arquitetura estiver mal implementada.

Portanto:

GraphQL não é REST melhorado.

São modelos diferentes.

---

⚡ CAPÍTULO 5 — gRPC PARECE ESTRANHAMENTE FAMILIAR AO COBOLZEIRO

Mitsuha escreve:

CALL 'AUTORIZA'
    USING WS-CARTAO
          WS-VALOR
          WS-RETURN-CODE.

O programador sorri.

Finalmente alguma coisa familiar.

Então ela desenha:

SERVIÇO A

   chama

SERVIÇO B

RPC significa Remote Procedure Call.

A ideia geral é fazer uma operação localizada em outro processo ou máquina parecer, conceitualmente, uma chamada de procedimento.

gRPC é uma tecnologia moderna muito utilizada nesse universo.

Normalmente os contratos são definidos com Protocol Buffers.

Por exemplo:

service PaymentService {

    rpc Authorize(PaymentRequest)
        returns (PaymentResponse);

}

Temos um contrato bem definido.

Uma vantagem importante é a possibilidade de geração de código para diferentes linguagens.

Podemos ter:

Java
   |
  gRPC
   |
   v
Go Service

ou:

Python
   |
  gRPC
   |
   v
Java

Protocol Buffers utiliza representação binária compacta, diferentemente do JSON textual tão associado às APIs REST.

Isso torna gRPC particularmente interessante em muitos cenários de comunicação interna entre serviços.

Easter egg COBOL

O veterano olha para aquilo e comenta:

— Então inventaram CALL USING pela rede?

Não exatamente.

Mas como modelo mental inicial para nosso Padawan COBOL?

Funciona maravilhosamente bem.

---

🔥 CAPÍTULO 6 — WEBSOCKET MANTÉM O PORTAL ABERTO

Agora Mitsuha pergunta:

— Como você descobriria se apareceu uma nova mensagem?

O aprendiz responde:

— Perguntaria.

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Parabéns.

Você acabou de descobrir o polling.

Dependendo do problema, polling é perfeitamente aceitável.

O problema aparece quando milhares de clientes perguntam repetidamente:

mudou?

mudou?

mudou?

mudou?

mesmo quando nada mudou.

WebSocket permite manter uma conexão de comunicação bidirecional.

CLIENTE <====================> SERVIDOR

Depois de estabelecida a comunicação, ambos podem transmitir informações.

Isso é extremamente útil em:

chat
jogos multiplayer
dashboards
colaboração
telemetria
atualizações interativas

Imagine nossa War Room Mainframe:

           IBM Z
             |
       SMF / MONITOR
             |
             v
          Backend
             |
        WebSocket
             |
             v
+---------------------------+
|    WAR ROOM MAINFRAME     |
+---------------------------+
| CPU                 73%   |
| CICS RESPONSE       0.2s  |
| MQ DEPTH            173   |
| DB2                 OK    |
| BATCH               OK    |
+---------------------------+

Se algum indicador muda, o backend pode enviar imediatamente uma atualização.

---

📡 CAPÍTULO 7 — SSE: MITSUHA LIGA A ESTAÇÃO DE RÁDIO

Nem sempre precisamos de comunicação nos dois sentidos.

Às vezes queremos principalmente:

SERVIDOR
   |
   |
   |
   v
CLIENTE

É aqui que entram Server-Sent Events, ou SSE.

O cliente estabelece uma conexão HTTP e o servidor pode continuar enviando eventos.

Pense numa estação transmitindo:

evento 1
evento 2
evento 3
evento 4

Isso combina muito bem com:

notificações
feeds
status
progresso
logs
streaming de respostas

Um exemplo moderno está nas aplicações de IA.

Imagine esperar 40 segundos para receber:

RESPOSTA COMPLETA

Podemos, em vez disso, transmitir progressivamente:

COBOL

COBOL foi

COBOL foi criado

COBOL foi criado no...

A experiência percebida pelo usuário melhora muito.

WebSocket versus SSE

Guarde este desenho:

WebSocket

CLIENTE <==========> SERVIDOR


SSE

CLIENTE <----------- SERVIDOR

Precisa de conversa contínua nos dois sentidos?

WebSocket pode fazer sentido.

O servidor precisa principalmente transmitir atualizações ao cliente?

SSE pode ser uma solução mais simples.

---

🔔 CAPÍTULO 8 — WEBHOOK: “MITSUHA, EU TE AVISO”

Agora chegamos a um dos conceitos mais elegantes.

Imagine Mitsuha esperando um pagamento.

Uma estratégia seria:

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Polling novamente.

Mas podemos inverter.

Mitsuha informa:

Quando acontecer,
mande a informação para cá.

Ela registra um endpoint:

https://loja.example/events/payment

Quando o pagamento acontece:

Sistema de pagamento
        |
        | HTTP POST
        v
Webhook Mitsuha
        |
        v
Processamento

Simples.

Até chegar a produção.

Porque o endpoint pode estar indisponível.

Então precisamos pensar em:

retry
timeout
backoff
assinatura
segurança
logs
monitoramento
duplicidade
idempotência

E aqui aparece um monstro fantástico.

---

👹 CAPÍTULO 9 — O DEMÔNIO DA DUPLICIDADE

Imagine:

Mitsuha envia pagamento de 100 moedas.

O servidor recebe.

Processa.

Debita.

Mas quando vai responder:

HTTP 200 OK

a conexão cai.

Para Mitsuha:

?????????

Ela não sabe se o pagamento aconteceu.

Então tenta novamente.

Se o sistema simplesmente processar outra vez:

100 moedas
+
100 moedas
=
200 moedas

Temos um problema sério.

Por isso sistemas de pagamento frequentemente trabalham com conceitos de idempotência.

Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indevidos para a mesma intenção.

Podemos associar à operação uma chave:

IDEMPOTENCY-KEY:
PAY-20260925-000317

O servidor registra:

PAY-20260925-000317 = PROCESSADO

Se receber novamente:

PAY-20260925-000317

ele consegue reconhecer:

Eu já processei esta intenção.

Isso é extremamente importante em sistemas distribuídos.

E nosso easter egg apareceu:

03:17

Veteranos da War Room Bellacosa sabem que incidentes gostam de acontecer justamente quando ninguém gostaria de estar acordado.

---

📻 CAPÍTULO 10 — MQTT E O EXÉRCITO DE PEQUENOS DISPOSITIVOS

Mitsuha agora possui:

10 sensores

Depois:

1.000 sensores

Depois:

100.000 sensores

Cada um precisa transmitir pequenas informações.

Temperatura:

27.3

Pressão:

1012

Estado:

ON

MQTT foi projetado pensando em comunicação leve e funciona muito bem em cenários envolvendo IoT, dispositivos e redes com restrições.

Seu modelo clássico envolve:

PUBLISHER
    |
    v
  BROKER
    |
 +--+--+
 |  |  |
 v  v  v
S1 S2 S3

O produtor publica em um tópico:

factory/machine17/temperature

Os interessados assinam tópicos.

A máquina 17 não precisa conhecer todos os consumidores.

Ela apenas publica.

Isso produz uma propriedade arquitetural valiosíssima:

desacoplamento.

O produtor não precisa saber necessariamente quem consumirá aquela informação.

---

📨 CAPÍTULO 11 — O COBOLZEIRO RECONHECE IBM MQ NA TAVERNA

Nesse momento nosso aprendiz interrompe:

— Espera. Publisher, consumidor, mensagens, filas, desacoplamento... isso parece mensageria.

EXATAMENTE.

Agora estamos chegando a uma ponte maravilhosa entre arquitetura moderna e mainframe.

Imagine:

COBOL
   |
   v
IBM MQ
   |
   +------> SISTEMA A
   |
   +------> SISTEMA B
   |
   +------> INTEGRAÇÃO

O universo corporativo trabalha há décadas com conceitos como:

filas
mensagens
persistência
transações
assincronicidade
store-and-forward
publish/subscribe

Por isso um profissional mainframe experiente frequentemente encontra conceitos supostamente “moderníssimos” e pensa:

Já enfrentei esse monstro antes.

Mudaram as ferramentas.

Mudaram os nomes.

Mudaram as abstrações.

O problema fundamental continua reconhecível.

---

🧠 CAPÍTULO 12 — NÃO SÃO REALMENTE “SETE PROTOCOLOS IGUAIS”

Existe uma correção conceitual importante na imagem que iniciou nossa aventura.

Colocar tudo sob o título “7 API Protocols” facilita a comunicação, mas tecnicamente mistura categorias diferentes.

REST é essencialmente um estilo arquitetural.

GraphQL envolve linguagem de consulta, sistema de tipos e runtime.

gRPC é um framework/sistema de RPC.

WebSocket é efetivamente um protocolo.

MQTT também é protocolo.

Webhooks representam principalmente um padrão de integração orientado a eventos.

SSE é um mecanismo padronizado para eventos enviados pelo servidor sobre HTTP.

Portanto, imagine a placa:

7 FORMAS IMPORTANTES
DE SISTEMAS CONVERSAREM

Ela seria menos sexy para LinkedIn.

Mas pedagogicamente seria mais segura. 😄

---

🧙‍♀️ CAPÍTULO 13 — MITSUHA DESCOBRE QUE FALTAVAM PORTAIS

Nossa lista também não contém todo o universo.

Precisamos conhecer pelo menos conceitualmente outros habitantes dessa dungeon.

SOAP

Foi extremamente importante na história dos Web Services empresariais.

Normalmente associado a XML e contratos formais, apareceu intensamente em integrações corporativas.

Ainda existem muitos sistemas utilizando SOAP.

AMQP

Importante no universo de mensageria.

Kafka

Apache Kafka popularizou arquiteturas baseadas em event streaming em enorme escala.

O modelo mental começa a ficar diferente de simplesmente:

manda mensagem
recebe mensagem
acabou

Eventos podem formar um registro persistente que consumidores processam conforme suas necessidades.

IBM MQ

Para o COBOLzeiro e para ambientes empresariais críticos, seria impossível discutir seriamente integração sem mencionar MQ.

Especialmente quando começamos a conversar sobre confiabilidade.

---

🏦 CAPÍTULO 14 — UMA ARQUITETURA REAL USA VÁRIOS PORTAIS

Agora Mitsuha finalmente constrói seu império financeiro.

O aplicativo utiliza REST:

MOBILE
   |
 REST
   |
API GATEWAY

Internamente alguns microsserviços conversam via gRPC:

SERVICE A
   |
 gRPC
   |
SERVICE B

O mainframe continua responsável por determinadas regras:

API
 |
 v
z/OS Connect
 |
 v
CICS
 |
 v
COBOL
 |
 +---- Db2
 |
 +---- VSAM

Eventos importantes passam por mensageria:

COBOL
 |
 v
 MQ
 |
 +------> Fraud
 |
 +------> Settlement
 |
 +------> Notification

O parceiro externo recebe:

WEBHOOK

O dashboard recebe:

SSE

O chat utiliza:

WebSocket

Sensores de algum equipamento poderiam utilizar:

MQTT

Veja o ponto fundamental.

Não escolhemos:

REST OU gRPC OU MQ OU WebSocket

Podemos escolher:

REST
+
gRPC
+
MQ
+
Webhook
+
SSE

porque cada tecnologia ocupa uma posição diferente na arquitetura.

---

⚔️ CAPÍTULO 15 — O VERDADEIRO CHEFÃO É O SISTEMA DISTRIBUÍDO

Nosso aprendiz agora conhece sete tecnologias.

Ele está feliz.

Mitsuha, porém, abre a última porta.

Atrás dela existe um monstro gigantesco chamado:

DISTRIBUTED SYSTEM

Porque aprender sintaxe é relativamente fácil.

O difícil é responder perguntas como:

E se a rede cair?

E se a mensagem chegar duas vezes?

E se não chegar?

E se chegar fora de ordem?

E se o servidor processar,
mas não conseguir responder?

E se o consumidor ficar offline?

E se eu tiver 10.000 consumidores?

E se uma operação demorar 40 segundos?

E se ocorrer timeout?

Posso tentar novamente?

Como sei o que aconteceu?

É aqui que entram conceitos fundamentais:

timeout
retry
backoff
idempotência
circuit breaker
dead-letter queue
observabilidade
correlation ID
tracing
autenticação
autorização
rate limiting

---

🔍 CAPÍTULO 16 — OBSERVABILIDADE: QUEM NÃO ENXERGA NÃO INVESTIGA

Imagine uma transação:

Mobile
  |
API
  |
Service A
  |
MQ
  |
COBOL
  |
Db2

O cliente reclama:

Meu pagamento desapareceu.

Onde?

Precisamos seguir a transação.

Um identificador de correlação pode ajudar:

CORRELATION-ID

TX-20260925-00042

Então conseguimos procurar:

API
TX-20260925-00042

SERVICE
TX-20260925-00042

MQ
TX-20260925-00042

COBOL
TX-20260925-00042

Agora a investigação deixa de ser:

Acho que o problema está no mainframe.

E passa a ser:

14:31:02.103 API recebeu
14:31:02.121 API publicou
14:31:02.135 MQ recebeu
14:31:02.148 COBOL iniciou
14:31:02.172 Db2 COMMIT
14:31:02.181 resposta publicada

Isso é ouro operacional.

Em ambientes modernos distribuídos, observabilidade não deveria ser decoração.

É parte da arquitetura.

---

🗺️ CAPÍTULO 17 — O MAPA DE DECISÃO DE MITSUHA

Quando precisar escolher uma abordagem, não comece pela tecnologia.

Faça perguntas.

Passo 1 — Quem inicia a conversa?

Cliente?

Servidor?

Dispositivo?

Outro sistema?

Passo 2 — Preciso de resposta imediata?

Se sim, um modelo síncrono pode ser apropriado.

Se não, mensageria assíncrona pode oferecer vantagens.

Passo 3 — Preciso manter conexão aberta?

Se não:

REST
GraphQL
Webhook

podem aparecer entre as possibilidades, dependendo do problema.

Se sim:

WebSocket
SSE
gRPC streaming

podem entrar na análise.

Passo 4 — A comunicação é bidirecional?

Se for:

WebSocket

merece investigação.

Se for predominantemente servidor → cliente:

SSE

pode ser suficiente.

Passo 5 — Tenho muitos produtores e consumidores desacoplados?

Pense em:

MQ
MQTT
Kafka
event-driven architecture

Passo 6 — Posso perder uma mensagem?

Essa pergunta muda tudo.

Pergunte também:

Posso duplicar?

Preciso manter ordem?

Preciso fazer replay?

Por quanto tempo?

Preciso comprovar processamento?

Agora estamos fazendo arquitetura.

---

💰 CAPÍTULO 18 — MITSUHA ENSINA A REGRA DAS 80.000 MOEDAS

Existe uma armadilha recorrente em tecnologia:

“X é moderno.”

Logo:

“Vamos usar X.”

Não.

Imagine usar WebSocket para uma operação executada uma vez por mês.

Ou GraphQL para uma API trivial com três campos.

Ou introduzir Kafka onde uma fila simples resolveria perfeitamente.

Ou fazer polling a cada segundo quando um webhook resolveria o problema.

Complexidade também custa dinheiro.

Ela produz:

infraestrutura
monitoramento
treinamento
suporte
incidentes
dependências
documentação
segurança
manutenção

Mitsuha não ficaria rica gastando 80.000 moedas para resolver um problema de 8 moedas.

Arquitetura madura procura a solução adequada, não a solução com maior quantidade de siglas.

---

🏛️ CAPÍTULO 19 — A CATEDRAL MAINFRAME JÁ CONHECIA MUITOS DESSES MONSTROS

Existe uma deliciosa ironia histórica aqui.

Hoje falamos constantemente em:

mensageria
eventos
transações
filas
RPC
assíncrono
publish/subscribe
observabilidade
alta disponibilidade
processamento distribuído

Muitos desses problemas são antigos.

Mainframes empresariais enfrentam há décadas desafios relacionados a:

milhares de transações
concorrência
integridade
recuperação
auditoria
segurança
mensageria
disponibilidade

CICS, IMS, Db2, MQ e outras tecnologias nasceram e evoluíram dentro dessa realidade.

Isso não significa que:

“Mainframe já inventou tudo.”

Seria exagero.

Significa algo muito mais interessante:

Os problemas fundamentais da computação sobrevivem às gerações de tecnologia.

As abstrações mudam.

Os protocolos evoluem.

As interfaces ficam mais elegantes.

Mas continuamos perguntando:

Quem envia?

Quem recebe?

Quando?

Em qual ordem?

Quantas vezes?

O que acontece se falhar?

---

🥚 EASTER EGG — A TRANSAÇÃO FANTASMA DAS 03:17

Às 03:17 da manhã, Mitsuha recebe uma ligação.

— Produção caiu!

Ela abre o dashboard.

REST funcionando.

CICS funcionando.

Db2 funcionando.

MQ funcionando.

Tudo verde.

Mesmo assim, pagamentos estão sendo duplicados.

Depois de duas horas investigando, encontra:

Webhook
   |
timeout
   |
retry
   |
processamento novamente

A aplicação consumidora não implementava idempotência corretamente.

O mesmo evento havia sido processado várias vezes.

Mitsuha olha para o aprendiz.

— Qual protocolo falhou?

Ele pensa.

— Nenhum.

Exatamente.

O erro estava no desenho do sistema.

Essa talvez seja a lição mais importante desta dungeon.

---

☕ EPÍLOGO — O COBOLZEIRO ATRAVESSOU OS SETE PORTAIS

Nosso jovem programador começou acreditando que precisava decorar:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Terminou entendendo algo muito maior.

Essas tecnologias representam diferentes maneiras de sistemas trocarem informações.

REST ensina a pensar em recursos e interfaces HTTP.

GraphQL permite ao consumidor declarar dados de que necessita.

gRPC aproxima sistemas distribuídos de um modelo de chamada remota baseado em contratos fortemente definidos.

WebSocket mantém um canal bidirecional.

SSE permite ao servidor transmitir eventos continuamente ao cliente.

Webhooks invertem o polling:

não fique perguntando; eu aviso quando acontecer.

MQTT apresenta um modelo leve de publish/subscribe extremamente útil para dispositivos e IoT.

E mensageria empresarial, MQ, event streaming e tecnologias relacionadas expandem ainda mais essa dungeon.

Mas Mitsuha ensinou algo que nenhuma tabela comparativa consegue ensinar:

Antes de escolher o protocolo, descubra a natureza da conversa.

Pergunte:

Quem fala?

Quem escuta?

Quem começa?

Precisa responder?

Precisa esperar?

Pode repetir?

Pode perder?

Precisa preservar ordem?

O receptor pode estar offline?

Quantos participantes existem?

Como descubro que falhou?

Como recupero?

Como provo o que aconteceu?

Quando um programador começa a fazer essas perguntas, alguma coisa muda.

Ele deixa de pensar somente:

COMO IMPLEMENTO ESTA API?

e começa a perguntar:

COMO ESTE SISTEMA DEVE SE COMPORTAR?

Essa é uma mudança gigantesca.

É a passagem da programação para a engenharia de sistemas.

E talvez seja justamente por isso que um programador COBOL possui uma vantagem inesperada nessa aventura.

Ele vem de um universo no qual palavras como:

transação
commit
rollback
fila
batch
online
integridade
recuperação
auditoria
disponibilidade

nunca foram apenas buzzwords.

Quando um pagamento envolve dinheiro verdadeiro, não basta desenhar uma seta bonita entre dois quadradinhos num PowerPoint.

A transação precisa chegar.

Precisa ser processada corretamente.

Precisa sobreviver a falhas.

Precisa poder ser investigada.

E, às 03:17 da madrugada, alguém precisa conseguir descobrir exatamente o que aconteceu.

Mitsuha fecha o mapa dos sete portais, guarda algumas moedas e olha para nosso Padawan COBOL:

— Então, qual é o melhor protocolo?

Ele finalmente aprendeu.

— Depende da conversa que os sistemas precisam ter.

Mitsuha sorri.

A primeira dungeon estava concluída.

A próxima porta tinha uma placa ainda mais assustadora:

                 EVENT-DRIVEN ARCHITECTURE

                          |
             +------------+------------+
             |                         |
          IBM MQ                     Kafka
             |                         |
       Queues / Topics            Event Streams
             |                         |
             +------------+------------+
                          |
                    COBOL PROGRAM

E alguém havia escrito em letras pequenas no canto:

ATENÇÃO:

“EXACTLY ONCE”
PODE CONTER MAGIA,
MARKETING
E MUITAS LETRAS MIÚDAS.

Mitsuha pegou novamente sua calculadora.

O COBOLzeiro preparou outro café.

E os dois entraram.