Event-Driven Architecture (EDA) e um padrao arquitetural onde componentes se comunicam atraves de eventos em vez de chamadas diretas. Quando algo acontece (um pedido e criado, um pagamento e confirmado, um usuario se cadastra), um evento e emitido e qualquer componente interessado pode reagir a ele. Em 2026, EDA e fundamental para microservicos e sistemas distribuidos.
O problema com comunicacao sincrona
Na arquitetura tradicional, servicos chamam uns aos outros diretamente via HTTP. Quando o servico de pedidos cria um pedido, ele chama o servico de pagamentos, que chama o servico de estoque, que chama o servico de notificacao. Problemas: acoplamento forte (o servico de pedidos precisa conhecer todos os outros), cascata de falhas (se o servico de notificacao estiver fora do ar, o pedido inteiro falha), latencia acumulada (cada chamada adiciona latencia), e dificuldade de adicionar novos comportamentos (novo servico = mudar o servico de pedidos).
Como EDA resolve
Com eventos: o servico de pedidos cria o pedido e emite um evento PedidoCriado. Qualquer servico interessado escuta esse evento: o de pagamento processa o pagamento, o de estoque reserva os itens, o de notificacao envia email. Nenhum servico conhece os outros. Adicionar um novo comportamento (ex: analytics) e so criar um novo consumer do evento, sem tocar no servico de pedidos.
Conceitos fundamentais
Evento: registro imutavel de algo que aconteceu. Tem timestamp, tipo e payload. Exemplo: PedidoCriado com id do pedido, itens, valor, cliente.
Producer: componente que emite eventos. Consumer: componente que reage a eventos. Event Broker: infraestrutura que recebe eventos e os entrega aos consumers. Kafka, RabbitMQ, Amazon SNS+SQS sao brokers comuns.
Tipos de eventos
Domain Event: algo significativo no dominio de negocio. PedidoCriado, PagamentoConfirmado, UsuarioCadastrado. Carrega dados relevantes.
Integration Event: evento para comunicacao entre servicos/bounded contexts diferentes. Geralmente mais generico e estavel na estrutura.
Event Notification: evento leve que apenas notifica que algo aconteceu, sem carregar todos os dados. O consumer consulta a fonte para detalhes.
Patterns de EDA
Event Sourcing
Em vez de armazenar o estado atual de uma entidade, armazena todos os eventos que aconteceram. O estado atual e reconstruido reproduzindo os eventos na sequencia.
Exemplo: conta bancaria. Em vez de armazenar saldo = R$ 1000, armazena: ContaCriada(saldo_inicial=0), DepositoRealizado(valor=500), DepositoRealizado(valor=800), SaqueRealizado(valor=300). O saldo atual (R$ 1000) e calculado somando os eventos.
Vantagens: audit trail completo (compliance), time travel (ver estado em qualquer momento do passado), debugging (reproduzir exatamente o que aconteceu). Desvantagens: complexidade, event store pode ficar enorme, queries complexas sao mais dificeis.
CQRS (Command Query Responsibility Segregation)
Separa o modelo de escrita (commands) do modelo de leitura (queries). Escritas usam o modelo de dominio completo (Event Sourcing, por exemplo). Leituras usam views otimizadas para cada caso de uso (materialized views, modelos desnormalizados).
Isso permite escalar leitura e escrita independentemente e otimizar cada lado para seu caso de uso.
Saga Pattern
Coordena transacoes distribuidas entre multiplos servicos sem transacoes ACID distribuidas. Cada step da saga executa uma acao local e emite um evento. Se um step falha, compensacoes sao executadas para desfazer os steps anteriores.
Exemplo: criar pedido (Servico de Pedidos: cria pedido, emite PedidoCriado). Reservar estoque (Servico de Estoque: escuta PedidoCriado, reserva itens, emite EstoqueReservado). Processar pagamento (Servico de Pagamentos: escuta EstoqueReservado, cobra cartao, emite PagamentoConfirmado). Confirmar pedido (Servico de Pedidos: escuta PagamentoConfirmado, confirma pedido).
Se o pagamento falha: emite PagamentoFalhado, Servico de Estoque escuta e libera a reserva, Servico de Pedidos escuta e cancela o pedido.
Implementacao com Node.js e RabbitMQ
// Producer – servico de pedidos
const amqp = require(“amqplib”);
async function emitirEvento(exchange, tipo, payload) {
const conn = await amqp.connect(“amqp://localhost”);
const channel = await conn.createChannel();
await channel.assertExchange(exchange, “topic”, { durable: true });
const evento = {
tipo: tipo,
timestamp: new Date().toISOString(),
payload: payload,
};
channel.publish(exchange, tipo, Buffer.from(JSON.stringify(evento)));
}
// Ao criar pedido:
await emitirEvento(“pedidos”, “pedido.criado”, {
pedido_id: “abc123”,
itens: [{ produto: “Notebook”, qtd: 1, valor: 4500 }],
cliente_id: “user_456”,
valor_total: 4500,
});
Desafios e cuidados
Consistencia eventual: em EDA, os dados nao sao consistentes imediatamente entre servicos. O estoque pode levar alguns segundos para refletir a venda. Para a maioria dos casos, isso e aceitavel. Para casos criticos (saldo bancario), estrategias adicionais sao necessarias.
Idempotencia: eventos podem ser entregues mais de uma vez. Cada consumer deve ser idempotente — processar o mesmo evento duas vezes deve ter o mesmo resultado que processar uma vez.
Ordenacao: em sistemas distribuidos, a ordem de chegada dos eventos pode diferir da ordem de emissao. Use event versioning e sequence numbers quando a ordem importa.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
