💣 Event-Driven Architecture explicada para quem já confiou em MQ às cegas

---

00:00 — Introdução: quando o sistema falava por bilhetes

Antes de Kafka, antes de cloud, antes de “arquitetura hexagonal”, já existia mensageria.
Mainframer raiz lembra bem: MQSeries, filas persistentes, mensagens garantidas, commit, rollback e aquele silêncio confortável de quem confiava que “se entrou na fila, chega do outro lado”.

A Event-Driven Architecture (EDA) nada mais é do que isso:
👉 sistemas conversando por eventos, não por chamadas diretas.

💥 Easter egg: quem já depurou mensagem envenenada em fila sabe mais EDA do que muito arquiteto de LinkedIn.

---

1️⃣ O que é Event-Driven Architecture (sem buzzword)

EDA é um modelo onde:

• Um produtor emite um evento

• O evento é colocado em um broker

• Um ou mais consumidores reagem a esse evento

• Nenhum produtor sabe quem vai consumir

Tradução mainframe:

“Eu jogo na fila e durmo tranquilo.”

---

2️⃣ Por que EDA virou moda (de novo)

Nos sistemas distribuídos modernos:

• Tudo é instável

• A rede falha

• Serviços sobem e descem

• Escalar síncrono vira gargalo

EDA resolve isso com:

• Desacoplamento

• Assincronia

• Resiliência

• Escalabilidade horizontal

📌 Curiosidade: o que a cloud vende hoje como inovação, o mainframe entregava há décadas com disciplina.

---

3️⃣ O paralelismo direto: MQSeries vs Kafka 🧠

MQSeries	Kafka
Fila	Tópico
Mensagem	Evento
Persistência	Log distribuído
Commit	Offset
DLQ	Dead Letter Topic
Retry manual	Reprocessamento

😈 Easter egg: Kafka não garante “exatamente uma vez” tão fácil quanto prometem. Mainframer já desconfiava.

---

4️⃣ Evento não é chamada de serviço (grave isso)

Erro clássico de quem vem do síncrono:

• Usar evento esperando resposta

• Criar dependência invisível

• Transformar EDA em RPC disfarçado

👉 Evento é:

• Algo que já aconteceu

• Imutável

• Registrado para sempre (ou até expirar)

💬 “PedidoCriado” ≠ “CriaPedido()”

---

5️⃣ Passo a passo mental para desenhar EDA

1️⃣ O que aconteceu? (evento)
2️⃣ Quem precisa saber disso? (consumidores)
3️⃣ O produtor precisa esperar? (não!)
4️⃣ O evento pode ser repetido? (sempre!)
5️⃣ Existe reprocessamento? (obrigatório)
6️⃣ O sistema aguenta mensagens duplicadas?

📎 Dica Bellacosa:
Se duplicar quebra, não está pronto para EDA.

---

6️⃣ Idempotência: o velho truque com nome novo

Mainframer conhece:

• Controle por chave

• Flags de processamento

• Tabelas de controle batch

No EDA moderno:

• Idempotência é obrigatória

• Consumidor deve aguentar evento repetido

• “Exatamente uma vez” é lenda urbana

😈 Easter egg:
Quem já escreveu batch reentrante já venceu essa fase.

---

7️⃣ Falhas fazem parte do design 🔥

Em EDA:

• Mensagem pode atrasar

• Consumidor pode cair

• Ordem pode se perder

• Evento pode ficar órfão

📌 Curiosidade:
No mainframe isso chamava reprocessamento controlado.
Na cloud chamam de resiliência.

---

8️⃣ Guia de estudo para mainframers migrantes 📚

Conceitos-chave

• Event-Driven Architecture

• At-least-once delivery

• Idempotência

• Eventual Consistency

• Dead Letter Queue

Ferramentas modernas (espírito antigo)

• Kafka

• RabbitMQ

• IBM MQ

• EventBridge

• Pub/Sub

---

9️⃣ Aplicações práticas no mundo real

• Integração entre sistemas legados e cloud

• Processamento assíncrono de pedidos

• Auditoria e rastreabilidade

• Desacoplamento de core systems

• Alta escalabilidade sem travar tudo

🎯 Mainframer com EDA vira arquiteto natural.

---

🔟 Comentário final (03:04, plantão eterno)

Event-Driven Architecture não é moda.
É mensageria com orgulho.

Se você já:

• Confiou em MQ sem ver o consumidor

• Lidou com DLQ às 06h da manhã

• Reprocessou lote sem duplicar dado

Então você já viveu EDA.

🖤 El Jefe Midnight Lunch decreta:
Quem entende filas, entende o futuro.