💣 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.














