Arquitetura Orientada a Eventos

No modelo mais simples de sistemas integrados, componentes se comunicam diretamente: o serviço A chama o serviço B, espera a resposta, e continua. Isso funciona bem quando os componentes são poucos, as dependências são estáveis e o volume é baixo. Quando a complexidade cresce — mais serviços, mais integrações, picos imprevisíveis de carga — a comunicação direta e síncrona cria fragilidades.

Arquitetura orientada a eventos (EDA — Event-Driven Architecture) é um padrão onde componentes se comunicam através de eventos — notificações de que algo aconteceu — em vez de chamadas diretas. O produtor do evento não sabe quem vai consumi-lo ou quando. O consumidor não sabe quem produziu. O acoplamento entre produtor e consumidor é mínimo.

"Pedido foi confirmado" é um evento. O serviço de estoque, o serviço de logística, o serviço de notificação ao cliente e o sistema de faturamento podem todos reagir a esse evento de forma independente, sem que o serviço de pedidos precise conhecer ou chamar cada um deles.

Evento: registro imutável de que algo aconteceu. Tem timestamp, tipo e payload com dados relevantes. "PedidoConfirmado, 2024-03-15T14:32:01Z, { pedidoId: 123, clienteId: 456, valor: 289.90 }". Eventos descrevem o passado — não são comandos ou requisições.

Produtor (publisher): o componente que gera e publica o evento. Não sabe e não precisa saber quem vai consumir. Sua responsabilidade termina na publicação.

Message broker / event bus: o intermediário que recebe eventos dos produtores e os entrega aos consumidores. É o coração da arquitetura — garante que eventos não se percam, que sejam entregues na ordem correta (quando necessário) e que múltiplos consumidores possam receber o mesmo evento. Kafka, RabbitMQ, AWS SNS/SQS, Google Pub/Sub são exemplos.

Consumidor (subscriber): o componente que escuta eventos e reage a eles. Pode haver múltiplos consumidores para o mesmo tipo de evento, cada um fazendo processamento diferente.

O benefício central de EDA é o desacoplamento temporal e espacial entre produtores e consumidores.

Desacoplamento espacial: o produtor não precisa conhecer o endereço dos consumidores. Se um novo serviço precisa reagir a "PedidoConfirmado", ele se registra como consumidor — sem modificar o serviço de pedidos. Adicionar funcionalidade sem modificar serviços existentes é uma das vantagens mais práticas em sistemas que evoluem.

Desacoplamento temporal: o produtor não precisa esperar que os consumidores processem o evento. Ele publica e continua. Os consumidores processam no próprio ritmo. Se um consumidor estiver temporariamente indisponível, os eventos ficam enfileirados no broker e são processados quando o consumidor volta.

Resiliência: falha num consumidor não afeta o produtor nem outros consumidores. O sistema degrada com elegância — o serviço de notificação pode estar com problema sem impedir que pedidos sejam processados.

Escalabilidade independente: consumidores que processam alto volume podem escalar horizontalmente sem que produtores ou outros consumidores precisem mudar. A fila absorve picos de produção enquanto o consumidor processa no ritmo que consegue.

Pub/Sub (Publish-Subscribe): produtor publica evento num tópico; todos os consumidores registrados naquele tópico recebem o evento. Modelo broadcast — o mesmo evento chega a múltiplos consumidores simultaneamente.

Message Queue: o evento vai para uma fila e é processado por um único consumidor (o primeiro a pegar). Modelo competitivo — múltiplos consumidores competem pela mesma fila para processar em paralelo, mas cada evento é processado apenas uma vez. Útil para tarefas de processamento onde o trabalho não deve ser duplicado.

Event streaming: eventos são armazenados em log imutável e ordenado (Kafka é o exemplo principal). Consumidores leem o stream a partir de qualquer ponto — podem reprocessar eventos históricos, múltiplos consumidores podem ler o mesmo stream em posições diferentes, e eventos são retidos por período configurável. Diferente de queues tradicionais onde o evento desaparece após consumo.

Event sourcing: padrão onde o estado do sistema é derivado da sequência de eventos, não de um snapshot do estado atual. Em vez de atualizar o registro do pedido diretamente, cada mudança de estado é registrada como evento ("PedidoCriado", "PedidoPago", "PedidoEnviado"). O estado atual é reconstruído replaying os eventos. Garante histórico completo e auditável de tudo que aconteceu.

CQRS (Command Query Responsibility Segregation): separação entre o modelo de escrita (comandos) e o modelo de leitura (queries). Frequentemente combinado com event sourcing — eventos de escrita alimentam modelos de leitura otimizados para consulta.

EDA não é solução para todos os problemas. Há compensações reais.

Consistência eventual: em sistemas síncronos, quando uma operação retorna sucesso, todos os sistemas estão consistentes. Em EDA, há delay entre o evento ser publicado e todos os consumidores terem processado. Sistemas que dependem de consistência imediata precisam de design cuidadoso.

Debugging e rastreabilidade: rastrear o caminho de uma operação através de múltiplos eventos e consumidores é mais complexo do que rastrear uma chamada síncrona. Rastreamento distribuído e correlação de eventos por ID de negócio são necessidades, não opcionais.

Ordem de eventos: em sistemas distribuídos, garantir que eventos sejam processados na ordem correta é desafio não trivial. Kafka garante ordem dentro de uma partição; entre partições, não há garantia.

Duplicação: message brokers geralmente garantem "at least once delivery" — o evento pode ser entregue mais de uma vez. Consumidores precisam ser idempotentes — processar o mesmo evento duas vezes deve ter o mesmo resultado que processar uma vez.

EDA é padrão arquitetural relevante para organizações com sistemas que precisam integrar múltiplos serviços com baixo acoplamento e alta resiliência. Para PMEs com operação digital significativa — e-commerce com múltiplos sistemas, plataformas com integrações variadas, operações com picos previsíveis de demanda — EDA resolve problemas reais de escalabilidade e resiliência que integração síncrona direta não consegue.

O ponto de entrada mais natural não é redesenhar toda a arquitetura — é identificar os casos onde a comunicação assíncrona via evento resolve problema concreto: envio de notificações após ação do usuário, sincronização de dados entre sistemas, processamento de background de operações demoradas. Introduzir uma fila nesse ponto específico, com RabbitMQ ou AWS SQS, já aplica a lógica de EDA sem transformação completa da arquitetura.